Thijs Kinkhorst is als Technisch Product Manager verantwoordelijk voor het… Meer over Thijs Kinkhorst
What was the problem again?
The challenge with federated logout is is that a simple, local logout button on an application (Service Provider or SP) by itself is not very effective. When the application's local session is terminated, and the user presses "login" on that application they will again be instantly logged in due to the active Single Sign On session on their Identity Provider (IdP). It is important to understand that all "Single Sign On" behaviour in our federation is implemented by the Identity Provider. Any login request to any service provider will be sent by SURFconext to the user's IdP, and the user's IdP will decide if the user has an active session and if so, redirect the user straight back via SURFconext to the service.
When application developers or users ask for a "logout" button, the first question should be what they actually mean for such a button to do. Suppose the user logs in via SURFconext to Blackboard, and later to their email. Then they press "logout" on the Blackboard application. What intention does this user express, what do they want to accomplish? Just being logged out in Blackboard, and continue working on their email? Or being logged out in all applications they logged into this session? Is it logical to initiate logout of your email via a button in the Blackboard application? Likely different users will expect different things. Most users may expect to be only logged out in the application where they used the link (we'll call that partial logout from now on). Others that do know about the existence of Single Log Out may expect to also be logged out of their email. So any of the two strategies may violate the principle of least surprise for some group of users.
Some attempted approaches
Nonetheless some approaches exist. In theory, the SAML 2.0 protocol facilitates a complete Single Log Out (SLO) from all applications the user has logged into in this session. However, this protocol depends on all involved service providers implementing it and be available at the time of logout. When starting a SLO, the user will be redirected between their IdP and all of the service providers sequentially, so each entity can perform their logout and pass control to the next one. If any of the service providers fails for whatever reason, the user receives an HTTP error and the logout process stops. A variant exists that tries to parallelise this by the use iFrames, however, most web applications nowadays send HTTP headers that block iFrame usage. We consider this approach too fragile to be reliable. Even if you'd accept this fragility, the question remains where the user would initiate this logout – from any of the service providers (likely does not do what they expect, see above)? Or some central portal? Will users find and use such a place?
Another approach is for SURFconext to implement a partial logout facility, reusing the Single Log Out protocol facilities from SAML. The service provider B can destroy the user's session and call the SLO endpoint of SURFconext, and SURFconext would call the SLO endpoint of the IdP. This destroys the session at the IdP. Other logged in Service Providers keep their active local sessions, but when accessing B again, or in fact any other SP that does not have a local session for the user yet, the user is asked by their IdP for their credentials. This could work in practice. It does still violate the element of least surprise for those users that would expect to be signed out everywhere.
Some service providers have also experimented with setting the ForceAuthn flag in AuthnRequests sent by their SP to basically disable Single Sign On always for their SP. This not only throws the advantages of SSO out of the window, it's also not watertight, because it's easy to bypass AuthnRequest flags. Not only because AuthnRequests to the IdPs are not signed in SURFconext, but also because many SP's support Unsolicited SSO (and you cannot disable this in popular implementations), via which you can log in to the SP without any preexisting AuthnRequest.
The common advice we currently employ is for the user to close all their browser windows. Besides being quite a blunt measure, it also quickly loses effectiveness since browsers now tend to keep session cookies active even across browser sessions, so closing those browsers has no effect on the user's login session.
Is the problem actually a problem?
Let's revisit the wish for a logout button. People implementing a "login" button often reflexively ask for it. But in the modern world, it actually seems a much less relevant feature than it once was. Let's first consider why people would want to log out. You want to log out to prevent someone else from using your session. This was a relevant thing when you used a public PC in the university library. Or when quickly using a friend's computer to look up your schedule for tomorrow.
But honestly, how relevant are these scenario's in 2020? If you want to look up your schedule or read your email while on the go – everyone has a device in their pocket that they own and do not share (the apps on this device are usually continuously logged in). The amount of public workstations on campuses quickly diminishes, and for those that remain one would surely hope that they reset their state after each use. If not, the problem is not in Single Sign On but in these workstations. And should you find yourself in a situation where you'd want to use someone else's computer – knowledge about using private browsing sessions is becoming mainstream and is an effective solution for this case.
So it's a fair question of how much we should still invest in devising more or less complex logout scenarios. However, I believe there's still something that can be done.
What can we do?
All the attempted solutions identified above approach the problem from the moment the user is done working. I believe however that we can much more effectively control the user's session life cycle if we approach it from the start. When the user first logs in, we ask him or her at the Identity Provider's login screen whether they'd like to have Single Sign On, that is, this is their own trusted device. If so, a single sign on session is started. If they do not select this option, e.g. when they are on a less trusted device, the login will work as normally, but any subsequent service provider they want to login to will just present the login screen again. This prevents the problems commonly associated with Single Sign On as presented above, is not hard to implement and the nice thing is that it requires only changes to the Identity Provider - that is, each IdP can for themselves decide to offer this to their users. In fact, several of them already have. It could look, or in fact already looks, like this:
It can be improved on further if the IdP would consider contextual factors of the user on whether or not to enable Single Sign On for the user. For example, are they inside the campus network or are they arriving with a previously (for them) unseen browser? This would make it even more user friendly, although also a bit more involved to implement. The above solution could therefore be a good starting point.
What do you think, is this something that would alleviate our current Single Logout woes?