The fusionSpan Blog

Synchronizing Single Sign-On (SSO) with a Domain Cookie, Part 1: An Overview

By Hans Stechl |July 19, 2018

Association Management Solutions (AMS)Implementations

There are a number of different implementations for Single Sign-On (SSO). SSO is generally approached in one of two ways – The first is a browser-side implementation which usually involves an integration that redirects the user to an Identity Provider’s login page (Identity Provider is the website that is the system of record in which the user accounts reside), while the second is a back-end integration that consumes an Identity Provider’s web services (API) to authenticate users.

The usefulness of most SSO implementations tends to end at the moment of authentication. This is sufficient when all is needed is to allow users to authenticate and validate the user’s authorization. Unfortunately, for organizations that own and manage multiple websites, the challenge beyond authentication lies with “synchronizing” the login sessions of all of the websites, and maintaining a seamless user experience which would ideally look something like this:

Single Sign-On: When the user Logs In to any of the websites, then whenever she/he navigates or is redirected to one of the other websites, she/he is automatically logged in.
Single Sign-Out: When the user Logs Out of “any” of the websites, she/he is unable to access restricted content on any of the other websites. In essence, the user is Logged out from the other websites as well.
Session Expiration: Whenever the Identity Provider’s session “Expires,” the user should not be able to access restricted content on the other Service Provider websites.
When a user’s session on a Service Provider website expires, it is automatically restarted if the Identity provider’s authenticated session is still active.

Imagine you work at ABC company, who owns and manages 3 websites:

An Identity Provider website: AMS.abc.org, and
Two satellite “Service Provider” websites: CMS.abc.org and LMS.abc.org.

Your customers can access courses and the community through the LMS and CMS websites respectively, and the AMS website is the system of record in which the user accounts are managed.

If you have the good fortune of having all of your organization’s websites on the same Top-Level-Domain (TLD) as in this case, “abc.org”, then a Domain cookie approach for a seamless SSO user experience might be a good option. Let’s examine how this works.

How it works:

AMS.abc.org is the Identity Provider. In other words, it is the system of record in which user accounts are managed, and it is therefore the website that will either serve the Login page, or will provide an API to be consumed by the other websites in order to authenticate users – note the latter assumes that the service provider websites are under our control and are trusted to pass-through the username/password. For our example, we will use the former.

Once a user successfully authenticates against AMS.abc.org, an authentication Token is issued and stored on the server – in some type of a database. A domain cookie (SSO cookie) is also created which contains aToken. The Token is temporary, unique, and very difficult to guess. A GUID works nicely. After this the user is redirected to the intended page. The intended page can be inferred from the URL referrer or can be specified in a URL parameter which is passed along with the URL when the user is sent to the Login page.

Because the websites share the same TLD and the SSO cookie is flagged as a domain cookie, the browser will send the SSO cookie along with any browser request to any of the websites on the same TLD – in our example, this includes LMS.abc.org and CMS.abc.org (both end in abc.org). When a request is made to a any of these Service Provider websites, the website inspects the SSO cookie, and takes the following actions:

If the SSO cookie exists, the Token is extracted from the SSO cookie, and is validated against the AMS API – The validation can take the form of an authenticated web service call (SOAP or REST).
If the Token is valid, the user is logged into the Service Provider website, and any additional user information authorized by the AMS to the Service Provider can be also requested from the AMS’s API.
If the SSO cookie does not exist, or the Token is not valid or has expired, the user is redirected to the AMS.abc.org Login page.

Below is a diagram that illustrates the flow:

AMS to the Service Provider

There are two mechanisms in place now that can help keep our sessions in Sync:

When the user logs out from any of the websites, she/he is redirected to a logout page on the AMS.abc.org website. This page invalidates the Token and deletes the SSO cookie. Then the user is redirected to the website from where she/he logged out. Since the SSO cookie is no longer available and/or the Token is no longer valid, the Service Provider will know to “clear” the current user session, and redirect the user to either the login page or another landing page.
Synchronizing Login timeouts is accomplished by setting a timeout on the SSO cookie, and keeping the Login session alive is accomplished by sliding the SSO cookie and Token by “tickling” the AMS website- this can take the form of an HTTP Handler on the AMS website that is referenced by every page on the Service Provider websites.

In-Process sessions can expire at any time on any of the websites – they do not have to necessarily be in sync. The user may still be “logged in” on LMS.abc.org even if the SSO cookie and Token are expired or deleted; for this reason LMS.abc.org MUST inspect the SSO cookie and validate the Token on every request. On the flip side, if the LMS.abc.org “session” expires due to idle time, the SSO cookie and Token can be inspected and validated when the user requests the next page which would automatically log the user back in and start up a new session.

We just released a follow-up to this post! Continue to Part 2 for technical considerations for an SSO domain cookie implementation.

If you have not already, click here to sign up to receive notifications on all fusionSpan blog posts.

Hans Stechl

Hans was one of the leading architects of netFORUM Enterprise. He is a BSIS Summa Cum Laude graduate of Strayer University. If Hans ever challenges you to a ping-pong match, decline - he lead his high school team to second in state. Now you're more likely to find him on the sideline cheering on one of his three kids who are all very active athletes!