Summary: A frequent concern when implementing Shibboleth is how users log out of an application once they are finished using it. People expect to be able to provide a log-out button within their application and that will force the user to log back in before using it. This assumption, however, has implications on the usefulness of Shibboleth and presupposes some requirements that the Shibboleth design cannot meet. It is my hope to clarify these issues and explain our position on their resolution.
Note: Two important key terms to know throughout this document are SP and IdP. In a Shibboleth transaction, the SP is the host of the application users are attempting to access and the IdP hosts the user and login data that identifies those users. For example, UCI has an IdP--we control Webauth and all Webauth's users--and At Your Service Online has an SP--they provide the AYSO application and all the data therein.
Understanding Shibboleth
It is important to understand the advantages of Shibboleth. Shibboleth is often called a single sign-on (SSO) service and that can lead to misinterpretations of it's benefit. At UCI, our SSO is actually Webauth. Shibboleth does not provide SSO functionality directly. Instead what it does is extend Webauth to outside the boundaries of UCI. It allows users at UCI to use Webauth credentials to access applications which are not aware of the workings of the Webauth system. Essentially, Shibboleth is an intermediary between UCI's Webauth and third-party service providers (SPs).
Expectations of the System
That said, Shibboleth still needs to seem like a standard SSO from the outside. It is an additional layer but it's important for that to be transparent to the user. Obviously, this means that a user should be prompted for the same username and password no matter what resource they attempt to access. A less obvious concern, however, is that a user should not be re-prompted unnecessarily. Additionally, a user should never log out of more applications than they realize. And finally, a user should never log out of fewer applications than they realize.
Meeting Expectations
Meeting these concerns can be a much harder topic that most people realize, and takes a modest understand of Shibboleth's work-flow to understand. For example, say you wish to allow an SP to initiate a log out on behalf of the user.
The SP could provide a log out button on their website, but what does it do? It could log the user out of the session on the SP's server, but this would not log a user out of Webauth and thus, whenever the user decided to revisit the website they would be automatically re-authenticated without being prompted for their password. This is logging out of fewer applications than expected.
So maybe, in addition to destroying the session on the SP server it sends a message to Webauth telling Webauth to log out as well. This works, but now say the user expected to only log out of the SP's site and was actually in the midst of a web session on one of the many Webauth-enabled applications. The application will see that they are no longer logged in and re-prompt them for their password. This is probably fine, though cumbersome to the user. But what if they were in the process of submitting a form online and data is lost. Even a small amount of data lost is worth attempting to avoid. Forcing a log out of webauth isn't an entirely unacceptable solution to this problem, but it also isn't without it's problems. This, however, is logging out of more applications than intended and getting re-prompted.
Backtracking a moment, let's say that the user clicked the log out button fully expecting to log out of every application they are currently logged in to. Maybe they are using AYSO, LMS and Connexxus all at once and they want a one-stop logout solution. Well, once a user logs in to a service, communication between the IdP and the SP ends. The IdP hands off control of the user session to the SP and forgets about it. There is no way for the IdP to tell if users are actively logged in to an SP, and there is no way for it to force an SP to log out all it's users. The reasons for this are both technical and logical, but it is something the designers of Shibboleth have stated for the moment will not be changed. Anyway, a user who clicks on a link and is logged out of Webauth will not be logged out of all active SPs and thus will be given a false sense of security that they have shut down their session. The only perfect way for users to log out of every session is to do each independently and an SP-initiated SLO gives the user the impression that they have accomplished this when they have not. This is very bad. And we're back to logging out of more applications than intended.
So far, all the discussion has been on the difficulties UCI faces, but log outs also have an impact on the SP. Still considering this idea of a logout button redirecting to UCI's webauth, remember that Shibboleth is meant to connect UCI webauth with third-party vendors. Those third parties will also want to connect to other clients, such as UCLA or UCB. If the logout button sends users to Webauth, that will have no effect on UCLA log outs. So each client will have to have a solution individually tailored to their system--violating the agnostic principle of Shibboleth's design. Shibboleth is supposed to make disparate systems function together without additional configuration. This kind of configuration bypasses Shibboleth and invalidates one of it's key advantages.
Okay, it's hard, so how do I log out?
The best solution is a well-designed session management on the SP's side combined with good training. Webauth logins only last as long as your browser is open. If users are trained to close their browser as the last step of using any system than there is no need for a logout button that redirects to Webauth, thus preventing any of the problems of premature logging out or confusion about what systems are closed.
If you can get the SP's to close their session on browser close, then it's the perfect solution, one that doesn't side-step Shibboleth's design. If you can't get the SP to close their session on browser close, simply shortening the session lifetime can do a lot to create secure sessions. Of course, training users to logout of the application and close their browsers, will completely solve the problem too--though less reliably.
That's not good enough.
We understand that this solution feels a little soft and that it seems like there should be a more solid solution. The truth is, there isn't much we can do. For those people that can make it happen and it's very important to them to have a functioning logout button, we advise the solution of getting the SP to redirect to Webauth's logout page. This is the most reliable solution for ensuring a logout, though we still believe it's not the best overall solution for managing session log out.
