Normally access protected websites offer a login and a logout. In federation scenarios the login is replaced with a Single Sign-On (SSO) that can be terminated by a Single Log-Out (SLO). The same Identity Provider may still offer the possibility to just login to one Service Provider if the user doesn't wish to enter Single Sign-On. This is in principle like the former (a website), but with distributed functionality. I've heard people that confused the Single Sign-On with just logging into a single Service Provider. Therefore when in doubt I use the terms Global for the federation and Local for the single Service Provider. E-authentication has another variant that they call simple logout, which I would call local logout. It's not clear what value it adds, but before further analyzing this I'll have a look at what the SAML specifications and E-Authentication says about it, starting with the definition of logout from the SAML Glossary:
- Logout, Logoff, Sign-Off
- The process whereby a user signifies desire to terminate a simple session or rich session.
The glossary doesn't say what's meant by a rich session. This is not important here though it would be interesting to know what they have in mind.
Once a principal has authenticated to an identity provider, the authenticating entity may establish a session with the principal (typically by means of a cookie, URL re-writing, or some other implementation specific means). The identity provider may subsequently issue assertions to service providers or other relying parties, based on this authentication event; a relying party may use this to establish its own session with the principal.
In such a situation, the identity provider can act as a session authority and the relying parties as session participants. At some later time, the principal may wish to terminate his or her session either with an individual session participant, or with all session participants in a given session managed by the session authority. The former case is considered out of scope of this specification. The latter case, however, may be satisfied using this profile of the SAML Single Logout protocol ([SAMLCore] Section 3.7).
The SLO protocol provides a means by which an authentication session and all associated RP sessions (i.e., initiated through that authentication session) can be terminated near-simultaneously.
- The RP MUST offer the end user a choice between simple logout (logging out only from the RP) and SLO.
- If the end user logs out while at a CS resource, the CS MUST terminate the end user’s authentication session and MUST initiate SLO (i.e., terminate all RP sessions associated with that authentication session).
- Before proceeding, the CS MUST inform the end user that he or she will be logged out of all active RP sessions, and the end user MUST confirm the request.
Is essence the SAML V2.0 specifications doesn't say anything about local logout - it is out of scope, whereas E-Authentication demands that the user is given the option. There's no formal conflict in this since E-Authentication is based on SAML V2.0 but has a wider scope.
Value added with local logout
Without wondering off into the question about what logout really gives in it self, just taking for granted that doing a logout is the right way in terms of freeing up resources. Users seldom do this a then the timeout takes over. Further consideration about timeout/logout I'll save for a later post.
My spontaneous judgment is that is doesn't add any value at all or even worse might give the end user a faulty conception. I might be missing something, but my reasoning is that if the IdP-session (at the Session Authority) is still active there's nothing to hinder that the local session is reestablished (SSO doesn't care about whether your starting afresh or returning). The only thing that could change this would be if SP has implemented a policy that after a local logout, a new local session can't be started on the basis of the same global session (that's SAML V2.0 "SessionIndex"). Since there's no mention of such policy I guess it's not implemented. Taking it further would be to say that local logout doesn't make sense in a SAML V2.0 federation scenario, and as such there's a contradiction in using SAML V2.0 and also demanding a local logout.