Enough with the articles about Single Sign-On! Much has been written about it and its undeniable benefits to both usability and security; users log into one, central website and receive unfettered access to a myriad of other web applications without encountering any other logon prompts. What about SAML Single Logout? After all, authentication is only the first half of the story.
What about the digital trail of websites the user seamlessly accessed and left in their wake? The user didn’t have to log in manually, so it’s easy for them to be unaware that they have other sessions open. End-users rarely log out of each session established during SSO. Technical blogs cover this issue even less. For the uninitiated, all these open sessions leave the door open for Cross-Site Request Forgery (CSRF) and session hijacking attacks. Anything that increases attack surface or the likelihood of a breach needs to be addressed, and SSO is no exception. That's where SAML Single Logout comes into play.
The SAML protocol is a popular choice for enabling SSO and contains a built-in feature called SAML Single Logout (SLO). This additional protocol helps address the problem of orphaned logins. SLO allows a user to terminate all server sessions established via SAML SSO by initiating the logout process once. SLO is initiated from either the Identity Provider (IdP) or any of the involved Service Providers (SP).
On the other hand, Universal logout is a hot topic today for one simple reason: it is important. Single Sign-On (SSO) has taken over in recent years as a method of reducing login strain and improving security while maintaining usability. In an age of passwords and data breaches, SSO has always been seen as the next logical step. Now that we’ve taken that step, the question becomes: where do we go from here? The answer is simple: we’ve secured logins, so let’s go ahead and secure the session integrity and termination by sign out of all accounts with Universal Logout.
Why Would I Want Universal Logout?
Universal logout sounds like a grand idea – log me out of everything that I’ve used SSO to get into, and keep the bad guys from hijacking my session – but the real benefit goes much deeper. As noted by researchers at Aalto University in Finland, “…users of SSO systems expect single Logout”. The real problem, however, is that not all SSO systems support what we consider Universal Logout. Universal Logout will address a need that users already assume is being taken care of – a dangerous assumption.
All things considered, the closest implementation that approaches true Universal Logout would be SAML Single Logout (SAML SLO). This feature is most commonly seen alongside Industry Standard protocols (SAML, Shibboleth, and even CAS). However, SAML SLO has one major flaw: not all parties involved support the feature. When SAML SLO is not supported, the logout request cannot be forced and sessions remain open and vulnerable. The IdP is not aware of this failure, however, and terminates its own session regardless.
It is because of this weakness that Universal Logout is necessary in the modern authentication environment.
Okay, so what IS Universal Logout?
Universal logout is conceptually simple: the Identity Provider initiates the logout manually from each Service Provider with an active session. This removes the requirement for ‘support’ of a new feature, and places the emphasis on security.
Universal Logout, at its most basic, is an effort to address the rising risk associated with a modern SSO landscape. As users evolve to take advantage of a secure but usable interface, attackers are finding more ways to prey on users who either ignore or simply don’t think to address active SSO sessions. In practice, SSO takes advantage of several browser cookies to provide a usable environment for end users to work in. Among these cookies, session cookies are utilized to keep sessions open when authenticated through an IdP for SSO. Typically, users logout of the IdP and assume that is the end of it. However, in those cases the individual session cookies are still valid until expired – the service never actually performed a logout. Hijackers can then use this active session to impersonate end users. The rest, as they say, is history.
Universal Logout addresses this potential vulnerability by terminating session cookies for open services when the IdP session is terminated – effectively forcing the logout of any active service.
Current SSO providers allow modification of the lifetime of session cookies to mitigate this risk, but this still puts the onus on the administrator. With this next step in authentication, the system will do all of the heavy lifting to enforce Universal Logout an secure user sessions.
SAML Single Logout - How It Works
There are different modes of operations within SLO. What follows describes the “Asynchronous” or “Front Channel” model which uses HTTP redirection through the end-user's browser. This is the model supported in our very own PortalGuard Single Sign-on product. There is also a “Synchronous” or “Back Channel” model which only involves server-to-server communication that does not utilize the user’s web browser as a conduit. The synchronous model is not covered in this article.
The Front Channel behavior of SAML Single Logout has two different use cases: SP-initiated and IdP initiated. Each process of the Front-Channel model is detailed below.
SP-initiated SAML Single Logout
- The Initiating SP generates a digitally signed LogoutRequest SAML message and returns it to the end-user’s browser. This validates the request to the IdP.
- The IdP's SLO endpoint is appended with the LogoutRequest, which is a dedicated URL that expects to receive SLO messages. This entire URL is returned to the user’s browser via a 302 HTTP redirection response.
- The browser follows the redirect and requests the IdP’s SLO URL with the LogoutRequest in the query string.
- The IdP determines the other SPs that support SLO to which the end-user received SSO during the current logon session. The IdP then iteratively does the following for each participating SP:
- Generates a new, digitally signed LogoutRequest
- Redirect user’s browser to that SP’s SLO endpoint
- Waits for a LogoutResponse from the SP via the user’s browser
- Each SP terminates its own logon session for the end user after receiving and validating the LogoutRequest from the IdP.
- The IdP terminates its own logon session and sends a final LogoutResponse message that to the initiating SP. This matches the original LogoutRequest it sent it step #1. The response includes a flag telling the originating SP whether SAML Single Logout was either fully or partially completed.
- The SP displays a logout page to the end-user.
IdP-initiated SAML Single Logout
- User clicks a “Logout” link on the IdP on that calls into the IdP’s SLO endpoint/URL.
- The IdP determines the other SPs that support SLO to which the end-user received SSO during the current logon session. The IdP iteratively does the following for each participating SP:
- Generates a new, digitally signed LogoutRequest
- Redirect user’s browser to the SP’s SLO endpoint
- Waits for a LogoutResponse from the SP
- Each SP terminates its own logon session for the end user after receiving and validating the LogoutRequest from the IdP.
- Upon receiving the final LogoutResponse, the IdP terminates its session.
- The IdP displays a logout page to the end-user.
SLO is not a panacea, however, as it does have its own requirements and restrictions. For example, both parties (the IdP and the SPs) must support the SAML Single Logout protocol. The various logon sessions are not terminated if the SP does not support this protocol. Additionally, the user will not receive the appropriate notification of this failure. This represents a serious security issue that most end-users will not know how to remedy.
The definition of SLO in the SAML specification (section 4.4 of the Profiles document) is derided for being difficult to implement and fragile in the face of runtime errors or exceptions. The estimable folks that implemented the Shibboleth protocol wrote an illuminating round-up of their trials & tribulations when adding SLO to Shibboleth. These difficulties compound the fact that SSO vendors can view SAML single logout as a secondary feature that is often either poorly implemented or ignored and left out entirely.
A final consideration that must be addressed when contemplating SAML Single Logout is the varied nature of many SSO implementations. SAML SLO only works with SAML SSO installations (Such as SAML and Shibboleth), and will not integrate with other SSO protocols such as OAuth, CAS and WS-Federation. It is important to understand that in many SSO environments, a SAML Single Logout implementation will only mitigate issues of orphaned SAML sessions – not eliminate these issues entirely.
What the Future Looks like
SSO was a great step for access control authentication. In an age clamoring for the ‘death of the password’, SSO was able to take that drive and refocus it to fit the changing environment – blending both the old and the new. With any innovation, however, comes risks that require resolution before too much time has passed. The current SSO landscape supports intermittent methods of addressing the risks of open sessions, but support is the greatest enemy.
The future looks to take another great step with the use of an Identity Proxy to enforce Universal Logout. This upgraded Identity Provider will be utilized to integrate with more services – including those that do not support standard industry protocols. In addition to this support, the Proxy will utilize Universal Logout to manage the termination of all active sessions and prevent hijackers from sneaking in behind the scenes.
As is the case when technology doesn’t adequately address an issue, the responsibility then falls to the end user. It’s easy to pass this off as a “user education” issue, but that rarely goes well. Consequently, the best defense against orphaned logins and improper logout procedures is to require users to shut down all browser windows and tabs. However, policies and best practices tend towards subjectivity and administrative discretion as opposed to required end-user practices. In conclusion, if the industry does not invent a better mouse trap, SSO session termination will persist as a problem waiting to be exploited.
Implementing SAML SSO
Before discussing SAML SLO or Universal Logout, organization first need a product that can create a single or federated authentication process to handle multiple local and cloud applications, while providing a centralized point of secure access. Implementing a SAML (Security Assertion Markup Language) SSO option with PortalGuard as the Identity Provider achieves the goal of eliminating password issues while providing more:
- Reduce the number of passwords users are required to remember and manage.
- Implement and enforce configurable password policies.
- Reduce password-related Help Desk calls related to password and access issues, and many more.
Read more about the benefits of an SAML SSO option in our eBook here.
