Identity Provider and Service Provider Single Logout
The University of Texas at Austin’s Shibboleth Identity Provider based on SAML 2.0 does not support single logout (SLO). SLO is the process of reversing the single sign on (SSO) process by destroying all sessions that are created while using SSO. For the context of this document, that would mean destroying the identity provider session and service provider sessions. Before explaining this in more detail, there are a couple of important terms to know.
This document will refer to a service provider (SP) which is the host of the service or application that users are attempting to access and the identity provider (IdP) which hosts user authentication and user attributes to be consumed by the SP.
For example, the university controls idp.its.utexas.edu which is the IdP used to allow users to authenticate using UT EID credentials and gain access to an SP. Services such as Canvas, Box and Qualtrics control the SP and application.
Understanding Shibboleth Single Sign-On Sessions
There are usually up to 3 sessions associated with Shibboleth IdP and SP integration: the IdP session, the SP session, and the optional web application session for the service the SP is providing. The following is the most common authentication flow for the creation of these sessions at a high level.
Whenever a user attempts to access an SP-protected application for the first time, they will not have an SP session or an application session and are redirected to the IdP to see if they have a valid IdP session. When they make it to the IdP, they also do not have an IdP session at this time and are prompted to provide UT EID credentials to authenticate.
Upon successful authentication, an IdP session is created and an associated IdP session cookie is placed in the user’s browser. The user is redirected back to the SP where the IdP session is verified and an SP session is created and an SP session cookie is placed in the user’s browser. Finally, the user is passed to the application itself where a web application session may also be created.
Upon returning to the application, the optional web application session is checked and then the SP session is checked. If either of these sessions are still valid, the user will not be redirected back to the IdP to re-authenticate. If neither of these sessions are valid, the user will be sent back to the IdP where the IdP session is checked using the IdP session cookie that was created upon initial authentication. If the user makes it back to the IdP with the IdP session cookie and the IdP session is still valid, the user will not get prompted to provide credentials. The IdP session will be refreshed and the user will be returned back to the SP and web application where new SP and web application sessions will be created.
If the user makes it back to the IdP without the IdP session cookie, or with an IdP session cookie but an invalid IdP session, the user will be asked to authenticate.
The Complications of Single Logout and User Expectations
When a user clicks on a logout button in an SP’s application, they have a set of expectations. These expectations combined with technical roadblocks currently keep SLO from being implemented.
When the logout button is clicked, the user’s web application session and SP session are ended, but the user is not logged out of the IdP. Therefore, if the user were to revisit the web application, they would be automatically re-authenticated because they still have a valid IdP session cookie.
In theory one might, instead of just destroying the web application session and SP session, have the SP tell the IdP to destroy its session as well. Unfortunately, the IdP does not know which SPs the user has sessions with, cannot inform those SPs to destroy the user’s sessions, and cannot enforce that those SPs destroy the user’s session on the SP and web application side. This creates a false sense of security for the user because they may believe that they have been logged out of all systems. It also means that the user could go from SP to SP and get varying experiences after logging out of one SP.
How do I properly logout of the IdP?
The best way to end an IdP session after logging out of an SP-protected web application is for the user to close their browser so that the IdP session cookie is destroyed. We recommend that, upon logging out, SPs direct their users to an unprotected page instructing them to close their browser, accordingly.
More information about this topic can be found here:
Last updated July 3, 2013 @ 1:45 pm