NOTE: This article details how Cross-Site Login works as of 09/02/20.
Cross site login is the ability to be logged in to multiple microsites as the result of a single login. The user must be logged into the main microsite before being redirected to any subsequent microsite. The setup instructions in this article demonstrate this.
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 taken 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 Cross-Site 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 is detected and used to authenticate the user into the microsite. After the key has been authenticated, it is destroyed so that 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 provides a Cross-Site Login Key (CLK) that is associated with the user's main-site session and reloads the page to https://{microsite}/home?CLK={CLK value}.
When the page is reloaded, the CLK is detected and used to create a session on the microsite for the user. If the user does not have an active session on the main site, the generated script is empty and causes no action.
Important notes
- Third-party cookies - In order for passive authentication to work across domains, users must have third-party cookies enabled. When making a client-side request from one domain to another and third-party cookies are disabled, all third-party cookies are set to SameSite=Lax, meaning they can be transmitted only 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.
This behavior is how cookies work when making requests with client side JavaScript. If the user has blocked third-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. - HTTPS - All sites must be HTTPS for third-party cookies to work correctly; they can be transmitted in a secure context only. 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 - Active login will still work if the user has disabled third-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.
Set up cross-site login
Variables (enclosed in curly braces)
- 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() - Encode the contents of the parentheses using an online tool (e.g., https://www.urlencoder.org/).
CrossSiteLogin.aspx
Set the following configuration parameters:
| Option | Notes |
|---|---|
| SignOffUrl | /HigherLogic/Security/Logout.aspx?CrossSiteLogout=1&ReturnURL={LogoutPage} |
| SignOnUrl | {LoginPage}=URLENCODE(https://{MainMicrositeDomain}/HigherLogic/Security/CrossSiteLogin.aspx?CrossSiteReturnUrl=) |
Example Tenants: NACE, UFAA
IMPORTANT: Some clients are set up to use RouteRedirect.aspx for authentication across domains. RouteRedirect.aspx works only because of the passive authentication process outlined above and has a dependency on third-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 method outlined above.
Exceptions
Personify
If the site uses the default Personify user provider, TmaUserProvider, the only changes you'll have to make to the typical SSO setup are:
| Option | Notes |
|---|---|
| SignOffUrl | /HigherLogic/Security/Logout.aspx?CrossSiteLogout=1&ReturnURL={LogoutPage} |
| SSOUseCrossSiteLogin | True |
CrossSite Logout
Pre-09/02/20 behavior
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.
Post-09/02/20 behavior
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.
Frequently asked questions
The user has disabled third-party cookies, can they still use passive authentication?
- No.
When I test cross site login in a normal window and attempt to do it in an incognito window the passive authentication flow breaks. Why?
- When using an incognito window in Chrome it will by default block 3rd party cookies.
The tenant is experiencing issues with Cross-Site Login.
- Make sure that HTTPS is enabled for all sites and that they have been properly configured for CrossSiteLogin using the steps outlined above. If the user is wanting a passive login experience that can only be done if third-party cookies are enabled in the browser.
How do we set up SAML for Cross-Site Login?
- Set the SignOnUrl to the absolute path of LACS page on the main site with the ReturnURL set to the absolute path of main site CrossSiteLogin.aspx page. For example: https://examplemain.site/HigherLogic/Security/SAML/LocalAssertionConsumerService.aspx?ReturnURL=https%3B%2F%2Fexamplemain.site%2FHigherLogic%2FSecurity%2F
CrossSiteLogin.aspx%3FCrossSiteReturnUrl%3D
What about OAuth using OAuth2UserProvider?
- Same pattern as SAML: https://examplemain.site/HigherLogic/Security/Oauth/SignIn.aspx?ReturnURL=https%3B%2F%2Fexamplemain.site%2FHigherLogic%2FSecurity%2F
CrossSiteLogin.aspx%3FCrossSiteReturnUrl%3D
What about OIDC using OidcUserProvider?
- Same pattern as OAuth: https://examplemain.site/HigherLogic/Security/OIDC/SignIn.aspx?ReturnURL=https%3B%2F%2Fexamplemain.site%2FHigherLogic%2FSecurity%2F
CrossSiteLogin.aspx%3FCrossSiteReturnUrl%3D
What about X UserProvider or X SSO that has dynamically generated authentication requests?
- If the authentication request to the SSO portal must be generated dynamically (as it does with OAuth, OIDC, SAML, iMIS Rest/Cloud, etc.), set the sign-on URL to the absolute path to the relevant .aspx page using the main site domain. For example: https://examplemain.site/HigherLogic/Security/SomeRandomSsoSignInPage.aspx?ReturnURL=https%3B%2F%2Fexamplemain.site%2FHigherLogic%2FSecurity%2F
CrossSiteLogin.aspx%3FCrossSiteReturnUrl%3D