CMS SSO handshake takes place too late in the HST Request Processing

This is a very complex catch 22 issue which only manifests itself under very specific conditions.

The way the SSO is currently handled is as follows:

1) The HST request matching is done. As a result, typically, there is on the HstRequestContext a ResolvedSiteMapItem (and ResolvedMount), which via #getHstSiteMapItem has a reference to the backing HST Model
2) During HST pipeline processing, the CMS Security Valve is hit. The, if the request turns out to be a CMS (channel mgr) request, there will be an SSO check: If there is not yet an http session or not yet a cmsSessionContext for an existing http session, a redirect (via browser) to the CMS webapp will be done, which in turn will redirect backto the site webapp with some request parameters which makes it possible to couple the site webapp http session to the cmsSessionContext. After this, the SSO has been established. Note that we do get

site webapp request X for channel mgr --> 302 to cms webapp --> 302 to site webapp with request X and some extra params

After the SSO has been established in the CmsSecurityValve, the HST request processing continues to the next Valve.

However, we now have potentially an issue : WHAT if the presence of a some attribute in the cmsSessionContext its payload should had been present DURING matching phase? For example some developer has a sitemapitemhandler which uses the cmsSessionContext to add some logic? Or what if via the HstSiteProvider support, some downstream project returns a different branch for an HstSite depending on cmsSessionContext payload attributes? Then, we are too late when the SSO is done in the CmsSecurityValve since the matching phase has already taken place.

Obviously, zooming out from the specifics above, it makes more sense that we do the SSO handshake at the earliest possible moment in the HST request processing possible : aka, that is when we can know the request is a CMS (channel mgr) request. At that moment, we can already detect whether the SSO handshake has been done (aka, for the site http session we can get hold of the cmsSessionContext). If no such handshake has been done, first establish one and do not continue processing the request.