Skip to content

Provided to you by GÉANT3 Identity Federations — read more

Single Logout

Author: Kristof Bajnok, NIIF.

While single sign-on means creating a new session based on a session at the IdP, single logout profile specifies a method to remove all sessions (both at the IdP and all of the SPs) at once. The trivial solution would be to reverse the process of SSO, but it would not work in practice because the user might get stuck between redirects if one of the parties do not respond. The biggest threat about Single Logout is that it can lead to false sense of security by giving the user the sense that he/she can leave the browser unattended. Therefore every logout implementation must ensure that each active sessions are terminated once it reports logout success to the user.

On a technical level, IdP and SPs communicate with each other by using SAML2 LogoutRequest/LogoutResponse messages. These messages can be transferred using either front-channel binding (HTTP-Redirect in practice) or back-channel (SOAP). SAML specification has the recommendation that if the Single Logout process is initiated by an SP, then the initiating request should be made via front-channel, in other cases, SAML2 Metadata may be used to determine the appropriate binding and endpoint.

Current implementations

At the time of writing of this deliverable, the major SSO software support Single Logout as follows:

  • Shibboleth IdP: does not support SLO (a fork which provides Single Logout support is maintained by NIIF )
  • Shibboleth SP: supports SLO on front-channel and back-channel bindings
  • SimpleSAMLphp IdP: supports Single Logout on front-channel bindings
  • SimpleSAMLphp SP: supports SLO on front-channel, and as the latest stable branch (1.7) introduced SQL session store, it is possible to use SOAP logout as well.

Major logout challenges

Third party cookies

Both the SimpleSAMLphp and the Shibboleth IdP implementations solve the problem of the daisy-chain of redirects with an iFrame-based user interface for front-channel logout. By using this, the browser is redirected to the associated SP in an iFrame (the redirect contains the necessary elements for a SAML2 LogoutRequest). However, if certain third-party cookie restrictions apply, then the SP does not get its cookies. Third party cookie handling is very browser dependant; however it seems impossible to come up with a solution that could reliably transmit the cookies within a frame (or IFrame, IMG, etc), unless the SPs share a common domain or third party cookies are enabled (the latter is the default for the most popular browsers).

  • Alternative 1: do not rely on cookies when using front-channel. It requires the SP to use a session store that works without cookies. It is possible with SimpleSAML SP 1.7, and would be possible in theory with Shibboleth SP as well. It does not work at the moment, for reasons see section Application integration.
  • Alternative 2: use back-channel logout, which also does not require cookies, therefore it also needs heavy application support. However, it has at least three other problems:
    • unlike other back-channel messages, IdP-initiated back-channel messages require the response to be signed even if it’s using an encrypted TLS channel. The reason is that the SPs often use a well-known certificate for the HTTPS endpoint, which might not be the same as the one that can be authenticated with the metadata. Hence for authenticating the remote peer, explicit signing must be turned on.
    • if the SP is clustered without shared SP sessions (thus solely relying on node affinity), back-channel requests would probably not reach the SP node which the user is associated with.
    • many IdPs have a firewall which might not allow outgoing TCP connections to remote hosts

Application integration

Traditionally application integration efforts ended with creating an application session based on another (eg. Shibboleth SP) session. It did not involve run-time SP session checking and handling messages or notifications. However, offering single logout without proper application support could result in users leaving their application sessions without they requiring re-authentication, and this would undermine systems’ security.

If an application has its own sessions, there are two approaches to prepare for logout:

  1. When loading the application session, the application should check that the SP session is still valid. This requires direct modification of the application’s session handling.
  2. The application should provide an interface to remove a user’s session (only Shibboleth SP provides this mechanism). In the case of back-channel binding, the application should be able to do the session removal based on the SP’s Session-ID, therefore the application sessions should be indexed by this, which again needs direct modification of the application session initiation code. For front-channel binding, in theory, cookies could be used instead. As explained above, frame-based logout UIs can not deliver the cookies reliably, therefore this mechanism would not work with such front-channel single logout implementations.

Probably for the reason of facilitating cookie-based application session removal, Shibboleth SP refuses to invalidate SP sessions if it receives the LogoutRequest on some front-channel binding without a cookie. This restriction is a policy decision, however, unless a cookie-safe logout controlling user interface is invented, this behaviour blocks front-channel single-logout deployments, even if the application could handle logout events in some other way.

Avoiding stale sessions

In a single sign-on scenario, there are at least four sessions for a user, each created on top of the previous one:

  1. IdP authentication session
  2. IdP session (active authentications, associated SPs etc)
  3. SP session
  4. Application session

These sessions are usually implemented with different session stores, therefore they expire or time out independently. However, if single logout is introduced, it becomes a security problem if a session remains usable after the parent session is expired.

In order to avoid stale sessions, the IdP session should have a limited inactivity timeout (“soft timeout”, the maximum time between user activity) but an unlimited session lifetime (“hard timeout”, independent from user activity). The SP sessions must have a session lifetime, which is not longer than the inactivity timeout of the IdP session. The IdP must set the SessionNotOnOrAfter attribute in the authenticating Assertion according to its session inactivity timeout value. The SP must honour this attribute and set its session lifetime based on this information.

If the SP session lifetime or inactivity timeout is shorter than the IdP session inactivity timeout, then the user would possibly get an error message during single logout because of the expired SP session. IdP implementations could in theory exclude the SPs from the SLO, whose sessions are initiated earlier than the inactivity timeout, but none of them cares, though. Anyway, it’s not possible to avoid logout errors caused by SP inactivity timeout. Another option would be to treat “Session not found” errors as a successful logout response, but this would be quite dangerous, see the issue with back-channel logout and clustering above.

Administrative logout

If a user’s session is compromised or for some other reason an individual user needs to be kicked off, administrative logout could be used to terminate IdP and SP sessions without restarting or otherwise clearing all of the IdP sessions. However, none of the implementations offer administrative logout. Trivially, administrative logout can only work on back-channel bindings.

NIIF has developed a proof-of-concept implementation partially solving this with Shibboleth IdP. It is capable of invalidating an existing IdP session, or optionally send a LogoutRequest to every SP associated to that session. It is however not a complete solution, because the current IdP session API does not provide a way to list all sessions of the user, thus the implementation is only capable to manage the last created session. (If the user is logged in from another browser or changes IP address, a new session is created.) The API is subject to change with Shibboleth IdP v3, which would make such features possible, but currently it has no estimated release date.

Interoperability problems

The interoperability problems are mostly not product or implementation specific, but rather a difference between configurations. The default configuration of Shibboleth IdP SLO requires the logout messages to be signed, but neither Shibboleth SP, nor SimpleSAMLphp signs front-channel messages by default. Either the requirement should be dropped (which is a violation of the standard and is a possible security risk when using back-channel) or all of the SPs need to be configured to sign messages.

Logout deployment in federations

At the current state of the implementations, it is not advisable for federations to introduce Single Logout Profile federation-wide. Care should be taken that only those SPs promote single logout endpoints that have proper underlying application support. This is not really technically enforceable, so the education of the administrators is very important.

2 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Rainer says

    Why should the application check for stale SP-sessions? If the application’s URL-name space requires SP-authN in the web server, the SP would request a re-authentication before passing the request on to the application. What do I miss?

  2. Thomas Gundel says

    Interesting observations!

    In the Danish Public Sector federation (NemLog-in) our experience is that cookies in iFrames are reliable if the IdP set relevant P3P headers to allow third party cookies. For example, we have several big portals that use iFrames for visual integration of service providers where both portal and service providers authenticate users via the NemLog-in IdP (framed SPs are required to set the IsPassive flag).

    Further, we have experienced that POST binding for single logout is more reliable than Redirect binding – i.e. it doesn’t get stopped by browsers with limitations on redirects.

    A number of non-technical approaches are also used in our federation to mitigate logout issues: governance mechanisms like mandatory test cases ensure that SP implementations are of sufficient quality and handle logout correctly, recommendations to using SOAP binding for critical applications, and instructing end-users to close their browser after logout on the IdP front page. While these things don’t solve every problem they can create a big improvement.

You must be logged in to post a comment.