What is Single Log Out?

Single Log Out (SLO) is the process of reversing a Single Sign On (SSO) authentication session. SSO is often preferred by campuses because it can reduce the number of times a user needs to provide credentials (username/password) to campus web applications throughout the day.

A simple analogy:
Single Sign On (SSO) is like using your key fob to unlock all of your car doors at one time in order to keep them open at a tailgate party so that you can easily get in to grab additional items throughout the day. Single Log Out (SLO) is the action of locking your car with your key fob before heading to the game.

SSO is designed for convenience. SLO is designed for security. Sometimes these conflict. What if a neighbor accesses your car while you are not looking? What if you need to get back into your car several times after you locked the doors?

Ultimate security would have you unlock and re-lock your car each time you access it for items.

Ultimate convenience would not enable the ability to lock the car. 

What is Shibboleth?

Shibboleth is a popular authentication protocol that many campuses (especially InCommon federation participants) use to apply security to web applications that are used by members of the campus community. Shibboleth is popular because it is highly secure and easy to configure for both the campus and third party platforms, like Campus Labs. However, there is one tradeoff for the security and simplicity of Shibboleth that can cause user experience issues in specific use circumstances that are important to understand.

Limitations of Shibboleth Single Log Out

The Shibboleth protocol does not support Single Log Out by design.

The best and only way to log out of an authenticated session is to completely close the web browser when finished using a web application, like Campus Labs, secured by Shibboleth.

Practical Implications of SLO Limitation

In scenarios where users are using their personal device and do not share their device with others this SLO limitation is not particularly invasive since the user will likely perceive that the Campus Labs application only requires seemingly periodic authentication, similar to Facebook or other web services that want to make it easy for users to quickly access content.

However, in scenarios where multiple users will use the same device and browser in rapid succession (taking turns filling out a survey, using the Location tracking kiosk screen, etc...), and where it is unlikely that the browser will be closed after each log out attempt, users can unknowingly continue use of the application as a previous user who did not successfully log out.

Remedies for the Shibboleth SLO Limitation

1. Users not sharing a device

If it is rare that multiple users will use a single device to participate in surveys or location tracking, then the simplest remedy is to remind users to close the browser upon log out.  The Campus Labs platform offers a configuration option called a "Shibboleth log out URL" which allows a campus to define a URL that the system will direct the user to upon clicking the "Log out" button in the application. The content of the webpage is at the discretion of the campus but should contain a reminder to close the browser to complete the log out process.

* It is important to note that the presence of a Shibboleth log out URL does not guarantee a successful log out for each user, it is simply a mechanism to remind users to close their browser.

2. Users sharing a device

If it is common for users to share a device, or the campus would like to use the location tracking features of the application then a permanent change in authentication method to one that supports SLO is needed.  The Campus Labs platform supports the Central Authentication Services (CAS), Lightweight Directory Access Protocol (LDAP), and a proprietary authentication method based on Security Assertion Markup Language (SAML) that we call Generic Pass Through.

If you would like to employ either of these strategies please contact our support team by creating a help ticket. 

 

Technical Summary of Issue
Adapted from The University of Texas at Austin
https://www.utexas.edu/its/help/shibboleth/2299

Campuses using a Shibboleth Identity Provider based on SAML 2.0 do 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, in this case the Campus Labs platform that users are attempting to access and the identity provider (IdP) which hosts user authentication and user attributes at the campus to be consumed by the SP.

For example, the university controls idp.its.campus.edu which is the IdP used to allow users to authenticate using campus username/password credentials and gain access to an SP, like Campus Labs.

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 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.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Need More Help?

Additional Support

Powered by Zendesk