NOTE: This article reflects how Cross Site Login works as of 09/02/2020.

What is cross site login?

Cross site login is the concept of being logged into multiple microsites through a single login. The user must be logged into the main microsite before being redirected to any subsequent microsite (if you look at the setup instructions below, you’ll see how this is reflected).

How does it work?

There are two ways for a user to authenticate into a microsite.

• Active Login: when a user is on an off domain microsite and does not have an active session on the microsite when they click sign in they will be take to their SSO’s sign on portal with the ReturnURL set to https://{mainsite}/HigherLogic/Security/CrossSiteLogin.aspx?CrossSiteReturnUrl=. After authenticating on the SSO portal they will be redirected back to https://{mainsite}/HigherLogic/Security/CrossSiteLogin.aspx which will authenticate the user and create a CrossSite Login Key (CLK). The CLK will be included as a query string parameter when the user is redirected back to the microsite from which their authentication request originated. When the request for the microsite is made, the CLK will be detected and is used to authenticate the user into the microsite. Once authenticated this key is destroyed so it cannot be used again.
• Passive/Silent Login: when a user has an active session on their main site and navigates to an off domain microsite a script is dynamically generated from https://{mainsite}/HigherLogic/Security/CrossSiteLoginJS.aspx and inserted by MasterPageBase.cs if the user does not have a session on the microsite. This script will provide a CLK that is associated with the user’s mainsite session and reloads the page to https://{microsite}/home?CLK={CLK value}. When the page is reloaded the CLK is detected and is used to create a session for the user on the microsite. If the user does not have an active session on the main site the generated script is empty and causes no action.

Important things to note regarding passive login:

• Users must have 3rd-party cookies enabled in their browser: in order for passive authentication to work across domains users must have 3rd party cookies enabled. When making a client side request from one domain to another and 3rd party cookies are disabled all 3rd party cookies are set to SameSite=Lax meaning they can only be transmitted if a request is to and from the same domain. If the HLLogin cookie is set to SameSite=Lax it is impossible to detect the session on the main site domain when making client side request and the dynamically generated script will result in no action.
  The behavior described here is not an HL/OC implementation complication, but how cookies work when making requests with client side JavaScript. If the user has blocked 3rd party cookies, silent and passive authentication protocols for other applications across domains is likely not possible for the user. IDPs such as Okta, Auth0, Ping, Akamai, etc have articles documenting this very issue.
• All sites must be https: for 3rd party cookies to work correctly they can only be transmitted in a secure context. If the site is not set to use https passive authentication will not work, because all 3rd party cookies will be set to SameSite=Lax by the browser.
• Active login will still work: if the user has disabled 3rd party cookies for privacy reasons active login will not be impacted. The script that is dynamically generated by https://{mainsite}/HigherLogic/Security/CrossSiteLoginJS.aspx will be empty and produce no action regardless of the authentication status on the main site.

How to set up Cross Site Login

Variables (enclosed in curly braces in the setup instructions)

• LoginPage - The external login page of the identity provider with the return URL query parameter at the end with a blank value.
• LogoutPage - The logout page of the identity provider (optionally with a redirect back to HL).
• MainMicrositeDomain - The domain of the Main Microsite Group.

Functions

• URLENCODE() - Take the contents between the parentheses and encode using an online tool (e.g., https://www.urlencoder.org/).

CrossSiteLogin.aspx

Set the following Configuration Parameters:

Example Tenants: NACE, UFAA

IMPORTANT: Some clients are set up to use RouteRedirect.aspx for authentication across domains. RouteRedirect.aspx only works because of the passive authentication process outlined above and has a hard dependency on 3rd-party cookies being enabled. If a client is experiencing chronic issues with cross site login and is set up for RouteRedirect.aspx, they should be converted to the methodology outlined above.

Exceptions

Personify

If the site uses the default Personify user provider, TmaUserProvider, the only changes you’ll need to make to the normal SSO setup are the following:

CrossSite Logout

• Before 09/02/2020: when a user clicks sign out on the microsite their session will be terminated on the microsite and they will be directed to the main site to end their session there. If a user has multiple sessions on multiple off domain microsites those sessions will persist until the user navigates to the respective microsites.
  Upon navigation to another off domain microsite if the user currently has a session the dynamic script generated by https://{mainsite}/HigherLogic/Security/CrossSiteLoginJS.aspx to facilitate passive login will to take into account if the user does not have a session on the main site. If the user does not have a session on the main site, but has one on the microsite the dynamic script on page load will end the session for the user on the microsite. This behavior occurs to ensure that sessions are ended everywhere eventually. It is important to note that is behavior is not true single logout as seen with SAML and OIDC.
  However, if the user has disabled 3rd party cookies the session status on the main site is unknowable and the resulting dynamic script will logout the user out no matter--if the user follows the active login process, (clicks sign in, is taken to SSO portal, redirected to main site, creates a session on the main site, is redirected back to the microsite, etc), they will be logged in momentarily and when the page load completes the dynamic script will terminate their session or worse send them into a redirect loop.
• After 09/02/2020: when a user clicks sign out on the microsite their session will be terminated on the microsite and will be redirected to the main site and their session will be terminated there. If a user visits another off domain microsite that they had a session on that session will not be destroyed unless the user actively clicks sign out. The dynamic script originating from https://{mainsite}/HigherLogic/Security/CrossSiteLoginJS.aspx going forward will only run IF a user does not have an active session on the off domain microsite in question. This change is response to the unknowable session state on the main site when the user has blocked 3rd party cookies and the issues that it causes. There is a solution to terminate sessions everywhere across domains for a user, but the immediate need to address cross site login issues means that cross site logout is of lower priority.

FAQ