Summary

The University of Texas at Austin’s Enterprise Authentication Identity Provider is based on SAML 2.0 and does not support Single log-out (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 entauthn.login.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 SAML Single Sign-On Sessions

There are usually up to 3 sessions associated with a SAML 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 Log-out and User Expectations

When a user clicks on a log out 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 log out 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 SP to redirect the user to the IdP log out endpoint, which will end their IdP session and ask them to close their browser.

As an example, using the Shibboleth Service Provider software:

• Where your SP logout endpoint is: https://yourserver.utexas.edu/Shibboleth.sso/Logout, and
• The log out endpoint for the Enterprise Authentication IdP is: https://enterprise.login.utexas.edu/idp/profile/Logout

The combined logout link would look like:

https://yourserver.utexas.edu/Shibboleth.sso/Logout?return=https://enterprise.login.utexas.edu/idp/profile/Logout

If you are using a different service provider, please consult your service provider's documentation for more information.

Please note, as mentioned above, that this will only log the end user out of your SP and the IdP. This action will have no effect on active sessions with other service providers. As such, our log out page encourages end users to close their browsers to terminate any remaining sessions.

Log Out Redirects

Customers who previously used the UTLogin service may be familiar with UTLogin's ability to redirect a client to a specified web site after successful log out. This was proprietary functionality for UTLogin and is not supported by the Enterprise Authentication Identity Provider.

More Information

More information about this topic can be found here: https://wiki.shibboleth.net/confluence/display/CONCEPT/SLOIssues