Bridging Gaps Through Technology
Blog Home

Synchronizing Single Sign-On (SSO) with a Domain Cookie, Part 2: Technical Considerations

In the previous post, we went through an overview of SSO with a domain cookie. In this post, we’ll dig into some of the technical considerations when implementing this SSO solution.

System Overview

As an overview, here are the responsibilities of each website from the previous post:

  • AMS.abc.org (Identity Provider/System of Record):
    • Provides login page
    • Provides logout page
    • Manages Tokens and SSO cookie.
    • Provides SlideCookie page/handler (more on this below)
    • Provides API to validate Tokens
    • Inspects SSO cookie on every page request
      • Validates Token against API on every page request (server side)
      • Automatically logs the user in if the Token is valid.
      • Automatically logs the user out if the Token is not valid.
  • LMS.abc.org and CMS.abc.org (Service Provider sites):
    • Redirects user to AMS.abc.org Login page
    • Redirects user to AMS.abc.org Logout page
    • Inspects SSO cookie on every page request
      • Validates Token against API on every page request (server side)
      • Automatically logs user in if the Token is valid.
      • Automatically logs user out if the Token is not valid.

Note: While this example has the login page on the Identity Provider only, this solution can also be implemented with login pages on the Service Provider assuming the Identity Provider offers an open API, but does require additional development work.

Technical Considerations

As you’re getting into your SSO implementation, there are a range of technical aspects that you need to consider. Here are a few items worth thinking through as part of your implementation.

Session Synchronization

  • Sliding SSO cookie and Token (Tickling) – The “tickle” to slide the SSO cookie and the Token  can be accomplished by referencing the ams.abc.org “cookie-sliding” page or handler with an image tag  such as <img style=”display:none” src=”ams.abc.org/slidecookie”></img>
  • In-Process sessions between all of the websites do not have to be in synch. The SSO cookie along with the API validation will keep all of the websites informed if the user is authenticated. So a session can be restarted seamlessly for the user.

Redirect Loop

  • If you encounter a redirect loop, it is most likely related to the SSO cookie.
    • Check if the cookie is in fact being generated and has the proper Domain attribute. Fiddler is a good tool for this.
    • Check that the cookie is being sent to all of the websites. If it is not, then it might be an issue with Http to Https switching, or an inconsistent “Trusted Sites” configuration in Internet Explorer.
    • Individual users may also have blocked cookies on their browsers. Providing some basic error message text on the login page notifying them they will need to enable cookies to proceed. It may be worth analyzing your users prior to implementation to understand what percentage of your web visitors have disabled their login.

Security considerations

  • HTTPS: This is a general best practice of any website that requests or displays sensitive information. On a login page, make sure it is served over https such that communication is properly secured with a Secure Socket Link (SSL) Certificate issued by a Certified Authority (CA).
  • Secure Cookies: The SSO cookie should be flagged as a “secure cookie” by including the Secure attribute with the cookie. This instructs browsers to not send the cookie along with a request to an HTTP URL even if it is to a resource on the same domain.
  • HttpOnly Cookies: The SSO cookie should be set as “HttpOnly”, which is accomplished by setting the “httponly” cookie attribute. This helps protect the SSO cookie by instructing browsers to deny browser-side alteration to the cookie (i.e. using javascript)
  • CSRF: As with any cookie, your SSO cookie can be vulnerable to Cross-Site Request Forgery. Implementing the proper safeguards against CSRF is highly recommended. You can refer to the OWASPs cheat sheet for more info on CSRF: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Conclusion

SSO synchronization is more often than not an afterthought of SSO implementations. There are other methods to accomplish SSO synchronization between multiple websites, including those that are on different domains, however if your websites share the same Top-Level-Domain, then an SSO Domain Cookie approach is a simple and a fairly straightforward method to implement.

The following two tabs change content below.
Hans Stechl

Hans Stechl

Hans was one of the leading architects of netFORUM Enterprise. He brings over 16 years of experience working on the product, and is intimately familiar with the ins and outs of the software. Having recently left Abila, the opportunity to engage directly with associations has him excited about working with fusionSpan. 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!
Comment Image

Leave a reply