First, some humor.

The Difficulties of Single Logout

Since Shibboleth was developed, one of the most requested features has been Single Logout (SLO). Our lists are full of threads indicating that this feature is not as easy as it seems. This document is an attempt to collect and expound upon the difficulties of SLO.

The issues presented below are not a list of theoretical issues that may occur. Some of the developers have experience with SLO implementations in similar protocols and have experienced all or most of these issues. In addition, the Shibboleth team has received reports from sites that have tested the Hungarian SLO plugin and they have also encountered these issues.

Background

Before beginning to look at the issues surrounding SLO a brief description of how the majority of web applications track their sessions and the message flow within SAML 2 SLO is provided.

Web Application Session Tracking

Most web-based applications store data about currently active users within memory and index this collection of data with a randomly generated number: a session ID. This session ID is normally stored in a browser cookie so that each time the user returns the cookie is presented to the application and the application can find the relevant, current, session data.

SAML 2 SLO Messages and Flow

SAML 2 SLO may be initiated by either the identity provider (IdP) or service provider (SP). A SAML 2 SLO request contains: a NameID that indicates the user to be logged out and, optionally, a session index that corresponds to the optional attribute within the initial authentication statement. A SAML 2 SLO response contains a status URI that indicates whether the logout operation was successful.

The SLO message flow is as follows. Note, it is the responsibility of the SLO initiator to provide the user with information about whether SLO has succeeded or failed.

1. (If SP-initiated) An SP sends a logout request to the IdP
2. At the IdP, for each SP to which the user has authenticated:
   1. The IdP sends a logout request to the SP
   2. The SP attempts to destroys its session for the user and sends back a logout response indicating if this was successful
3. The IdP destroys its session for the user
4. (If SP-initiated) The IdP sends a logout response to the initiating service provider which then destroys its session

SAML 2 defines two broad means of transporting these messages; through the browser via HTTP POST or Redirect, known as front-channel bindings, or via direct IdP/SP SOAP messages, known as a back-channel binding.

The User Experience

In order for SLO to be successful a couple of requirements must be met from a user experience side:

• The user must understand that they are currently signed in to a single sign-on (SSO) system and what will result from clicking the logout button/link.
• The user must always know whether logout has completely succeeded. Otherwise they may assume that it has and leave the computer allowing some one else to erroneously access a service.
• The UI must meet various accessibility requirements (e.g. W3C Website Accessibility Initiative).

Communicating SLO

One of the first issues with SLO is communicating to the user what will occur if they click "logout". Users have already been taught that doing this will cause them to be logged out of the application that contained the logout button/link they used. They assume that all other applications will remain active. Therefore there must be some means to distinguish between application-level logout and SLO.

This issue is usually addressed by providing a consistent UI component across all participating applications. MS Passport, Virginia Tech's Authportal, and other systems, do this by placing a branded, distinct, image/button in place of the application-level logout link/button. When a user visits a site that participates in the SSO system the application displays a form of the UI component that indicates that the user may log in. When the user is logged in the UI component is changed to reflect this state.

This approach however suffers from two problems. First it requires educating users about this UI component and what it is meant to convey. Second, it requires all SPs display the same UI component. While the first issue can be solved through an education effort the second problem is practically untenable. Third-party SPs sell their services to many organisation and are unlikely to coordinate a different UI component for each one. It's also exceedingly unlikely that all organisations and SPs would agree upon a single, uniform, UI component.

Communicating Success/Failure

Another UI issue occurs during SP-initiated SLO. In this case it is the SPs responsibility to provide the final indication to the user about the success or failure of SLO. However, the amount of information that the SP gets back from the IdP is very limited; a URI that either indicates complete success or one that indicates some failure in the process. In the case where SLO fails the SP will have little information with which to tailor what it displays to the user since it will not know the cause of the failure. In almost all failure cases the sensible thing would be to tell the user to close their browser. This provides a way to deal with this issue, but it's not very elegant.

If a front-channel binding is used this problem can become worse. In the event that a SP is not responsive the user will be presented with an HTTP error. At this point neither the IdP nor the SP present information to the user. Some SLO implementation attempt to solve this by the use of frames. If implemented properly this can help ameliorate the issue.

Accessibility

Accessibility comes up in two places during SLO. First is the aforementioned logout UI component. Most sites seems to use an image for this. This poses a problem for visually impaired individuals. The solution to this is pretty simple; use a good, descriptive, alt tag for the image. Most sites do not seem to do this.

As previously mentioned, the mechanism usually used to deal with the HTTP errors, that can occur during the use of front-channel bindings, is frames. Most accessibility experts however find the use of frames to be unacceptable because of the great difficulty (or impossibility) of presenting such an interface to individuals with various impairments. Most web browsers meant to assist these individuals can not render various types of frames.

The Technical Difficulties

Front-Channel Bindings Revisited

One problem, that of conveying information to the user when an HTTP error is encountered during the use of a front-channel binding, has already been discussed. However, there is also a correlated technical problem. When the IdP is using a front-channel binding to send messages it is tossing complete control to the SP (which it hopes will be there to catch it). If the SP is not responsive the process breaks down and the remaining SPs will not receive logout requests. So, in addition to not being able to tell the user what has happened there are also SPs, with active sessions, that are unaware that a failed logout attempt has occurred.

The reason for the front-channel binding is so that the user's browser, with its session cookie, show up at the application. One use case for single logout, however, is an administrator forcing the cessation of another user's session (e.g. their account has been compromised, because the user is doing something bad, etc.). In this case it will be the administrator's browser, and not the user's, that will visit the service providers thus preventing the applications for accessing a session cookie and destroying it as the means to invalidate the session. The means for addressing this is provided later.

Back-channel Binding

The use of the back-channel binding can mitigate almost all the issues presented so far (except the lack of failure information in the SLO response during SP-initiated logout). However, like in the case with administrative logout over a front-channel binding the user's session cookie is not available to the application and so the same issues are present; inability to look up the user's session and destroy it.

SAML 2

Finally, there is the problem that only SAML 2 supports single logout. If any entity supporting only SAML 1 is participating in the SSO session they will be left out of the logout process. Attempting to explain to a user which services support SLO and which do not is unlikely to be successful.

The Policy Decisions

A final issue that people have raised with single logout is the question of who may initiate logout. Some organisations have concerns about allowing third-party applications to initiate a logout. Most of these concerns are rooted in the poor mechanisms currently used to communicate that the user is participating in an SSO session and that "logging out" will destroy their session on all applications.

An example case goes as follows. A student accesses the university's student information system, which participates in the SSO service. The student goes to register for classes and is reviewing possible courses. During this review process the student access some material from the library, which also participates in the SSO session, to see if the associated class is what they want. Because they have been taught to always logout of applications they click the logout link in the library application. This link is actually an SLO-enabled link and also destroys the session within the student information system.

So, some organisations wish to limit who can initiate a single logout to a set of applications that are under their control. A question then arises; what do you do if the user has only logged in to application outside the organisation's control? Users will either need to be taught that some applications can only initiate logout in certain situations or that if certain applications (third-party ones) are used they must close the browser instead of using the logout mechanism. Either message is unlikely to be understood by many users.

A Non-solution

When presented with these issues many individuals offer a protocol where only the initiating SP and the IdP communicate. The goal is to destroy the SP's session and the IdP's session so that users would have to re-authenticate if they visit that SP again. This approach leaves all other SP sessions active and communicating to the user exactly what they have, and have not, been logged out of is likely not possible. Therefore, this approach increases the risk that a user might abandon a computer with active sessions and allow an unintended, and possibly malicious, user access to those services.

To put it tersely, any application that would attempt this approach is looking out only for themselves at the cost of compromising the security for every other application participating in the SSO system.

Preparing a Web Application for Single Logout

A web application developer should do one of two things to support single logout when using Shibboleth. The easiest is to remove all application level session management and rely solely on the Shibboleth SP's session management. In addition to gaining SLO support the modified application will immediately gain new session related features as they are added to the Shibboleth product and eliminate any confusion that may occur if the application's session's configuration differs from that of the Shibboleth SP configuration (e.g. different session timeouts).

Web applications that do not rely on the Shibboleth SP session management will need to index their sessions by means of the Shibboleth session ID, provided by the SP in the Shib-Session-ID header. Then they must implement a callback script, that will be invoked when the SP receives a logout request, that will be destroy the user's session. Note, however, that the application MUST NOT assume that the incoming request bears the session cookie and the script must be designed with that in mind.

Conclusion

In summary, the issues surrounding the use of SLO generally fall in to either user experience issues or technical issues. Many user experience issues can be addressed if an organisation is willing to invest effort in educating its users (which requires an ongoing effort in order to catch new individuals). The user experience and correlated technical issue that occurs when an HTTP error occurs during the the use of front-channel bindings can not be addressed if accessibility requirements are also to be met. As such, back-channel bindings are most likely to be successful but usage requires web application to take the aforementioned prerequisite steps, work that many developers have expressed an unwillingness to undertake. This will leave many organisations at an impasse, choosing between a solution with a high risk of being insecure or forcing developers to make changes to applications throughout the organisation.