• Early draft 2008-02-09 by Andreas Åkre Solberg andreas.solberg@uninett.no

Table of Contents

To keep sessions on web sites, we use cookies RFC2965: HTTP State Management Mechanism. Cookies are limited to share a state / session between endpoints using the same domain name. Authenticated session requires users to enter som credentials each time a session is established. Consequently, a user has to re-enter credentials for every new domain. Single Sign-On protocols like SAML 2.0 eables propagating authenticated sessions between domains. This is considered convenient for the user because the user does not need to re-enter credentials for every site.

All service providers that share authenticatied sessions with an identity provider forms a federation. A user is not very likely to have a clear understanding of which services are part of a federation and which is not.

It is important provide some way of terminating authenticated sessions for users. Two factors increase the need for logout in a federation compared to stand-alone services:

• The authenticated session grants access to a very large number of services. At the same time the user is not aware of exactly which services can be accessed without re-logging in trough the authenticated session at the IdP.
• Federations often are about (among other things) increasing convenience for end-users. One way of increasing convenience is to increase the duration of the session at the IdP. As an example, in the norwegian federation Feide the duration of the session at the IdP is 8 hours. In comparison Internet banks often use session durations of only a couple of minutes.

1 Different Logout options

Here are four different approaches to handling logout in a federation.

1.1 Solution A: Not handling logout at all

Because of the difficulties of implementing and providing logout functionality, most federations choose to not provide logout at all.

This solution is based upon two facts:

• The default behaviour of most if not all web browsers is that when the browser is closed, all temproary cookies are deleted. This will terminate all authenticated sessions across all services that uses temporary cookies for keeping the session.
• Most users is used to close web pages in order to logout.

Why not use this solution?

1. There is some inconsistency in how browsers behaves when closing the browser. One example is Firefox, which will when you close the browser while having a download running while you close the browser, will not delete temporary cookies.
2. Service Providers may use persistent cookies to keep the authenticated session. The federation may restrict this by rules. Still, it may be difficult to control the behaviour of all service providers, and also it is almost impossible to tell by end-users whether a session is held by a temporary or persistent cookie.
3. When users close web pages to logout, I have a strong feeling, that to close a web page, then close the tab (and not the browser). in some cases, the user also would close the window (which is not the same as closing the browser, if more windows still are open). On the mac platform in particular, users are more used to closing windows, than applications. I do not have proper documentation to tell that this is how it is, but we saw some indications of this way of thinking when we performed SLO usability testing in February 2009, performed by Netlife Research. (As of now, the report from this usability testing is not ready)
4. Even if a logout impementation is provided to the user, the option of closing the browser will always be posssible for users that preferred this option.

1.2 Solution B: Local logout - at SP only

This is not a solution, but I include it anyway, as many think of this as a solution, and may be even implement and use it, not knowing how bad idea it is.

After a local logout, if SSO is enabled, the user may refresh the browser, or click login, to automatically get a new authenticated session. Obviously this is not the intenstion neither by the service provider or the user.

Some exception where it may be possible to use local logou (although not reccomended) is when the service provider always uses ForceAuthN="true" in the AuthNRequest to disable SSO.

1.3 Solution C: Logout at one SP and the IdP

To fix the problem with local logout the obvious next step is to propagate logout from the SP to the IdP. This means that when the user logs out from SP1, the authenticated session at the SP and the IdP is terminated, but other sessions are still active (SP2, SP3, etc).

The main problem with this solution is that the user does not have good control of which service the user is logged into and which server the user is not logged into. The border limits between services may be diffuse and inconsistent. Because the user has the SSO experience, the user gets no indication whent he user enters a new SP - the user is automatically logged in. It is common practice to bundle multiple services into a common Service Provider (to simplify the practical deployment). At the same time, the opposite example exists: in example the Feide OpenWiki acts as two Service Providers, the wiki part and the admin part, where the two wiki part if federated with a superset of the IdPs.

I would not reccomend this solution mainly because the users will not exactly what will happen when he/she logs out.

1.4 Solution D: Full federated SLO - propagated to all SPs

The most complex solution is where SLO is propagated from the initiator (SP) to the IdP and further to all other SPs with an active session.

This solution has several issues attached to it, that would need to be solved in order to provide a good experience to SPs and end users:

1. The SPs should not be forced to implement IdP-initiated SOAP SLO as it involves some extra challenges, not only at the SP but in the integration with the service it self. Then, only front-channel SLO is left, and that involves a new issue:
2. Front-channel SLO will open up for the scenario where the user initiates logout from SP1, and gets a 500 Internal Error at SP2 and is unable to complete logout. This is not acceptable neither for the end-user, the federation or SP1.
3. The user is not expected to fully understand the consequences of SLO, and initiating SLO may lead to the fact that the user is logged out from a service that the user not indented to logout from. Some examples of really bad effects are: large transactions beeing interrupted or large wiki page beeing edited will not be saved properly.
4. If only a subset of SPs implements SLO properly, it gives an inconsistent experience for the user. The solution may be for the federation to require that all SPs supports SLO.
5. Even if all SPs are required to support SLO, it is unlikely to expect that all SPs at all time works flawlessly. When exceptions arise, and SLO fails it is really important that the user is notified about exactly what happened, which SPs that user successfully is logged out form, and which is not.

2 The Feide solution to SLO

Feide has implemented a solution to SLO that works as follows:

The user initiates SLO by clicking logout at one of the service providers. We do not want to introduce complex concepts like SLO or global logout to the users, instead we would like to inform using UI about exactly is going to happen and what have been done.

When the user is clicking logout, a HTTP-REDIRECT LogoutRequest is sent to the Identity Provider.

The Identity Provider presents a HTML page to the user with the following information:

• You have initiated logout from SP1.
• Button1: (Logout from SP1 and IdP only)
• You are also logged in to the following services that supports logout:
  • SP2
  • SP3
  • SP4
• Button2: (Logout from all services above including SP1).

If the user is logged into a service provider that does not support logout at all (should be an exception if the federation requires that all SPs implements SLO. In example in shibboleth federation, it may be that some SPs still use he Shib1.3 protocol and do not support SLO), the user will be reccomended to close the browser to kill all sessions.

If the user clicks Button1, a successfull LogoutResponse is sent back to SP1, and SLO is not propagated to other SPs. This works as Solution C but solves the problem about notifying the user with UI about what is going on and what other services the user still is logged into.

If the user clicks Button2, the IdP presents a HTML page to the user including hidden iFrames that points to the SLO endpoints of all services. The href field of the iFrames will be a HTTP-REDIRECT LogoutRequest with IsPassive="true", and the user will then be logged out from all SPs in parallell. The LogoutResponse will be sent back to a endpoint at the IdP, and updates the status session of the SLO progress. The HTML page presented to the user lists a table of all SPs, and showing a spinng wheel icon for each SP, indicating the logout is in progress. As logout is successfully completed, a checkmark icon is displayed next to the SP name. If the SP is not responding the spinng wheel will just keep spinning, and after 15 seconds a information box is displayed to the user telling that some of the SPs probably is not able to be contacted and that the user should close the browser in order to be sure to kill the session. If a SPs reponds with an error message, a red cross icon is displayed next to the SP, and the user is notified about what actions is needed to be taken.

If all SPs responds successfully, the IdP is waiting 2 seconds in order to let the user get an impressions of all the checkmark icons, before the user is automatically sent back to the initiating SP with a successfull LogoutResponse.

The implementation has a fallback implementation that works without javascript, but with less fancy live update of the SLO progress.

The solution is implemented and part of the simpleSAMLphp code, available for anyone to use.

Here is a screenshot from an early version of the SLO implementation:

After that went through a usability testing, testing people from the street, on how they managed to use our new login and logout implementation. The results of the usability testing, will be reflected in some UI simplifications and improvements. These improvements will be completed before the end of February 2009.