Trust and Internet Identity Meeting Europe
2013 - 2020: Workshops and Unconference

TIIME 2013 Tuesday Session 2: SLO Single Logout for SAML & OAuth

Front channel or back channel solutions. Is there any vision for the SLO dilemma: a standardized solution

Austrian gov2gov federation with proprietary protocols, now implementing SAML

The former system was a revered proxy system and SLO was easy. But reversed proxy is a problem in its self. Using Shibboleth and OIO-SAML

Latest plan in Shib: basic single log out in IdP 2.4

Is Cookie stealing a Security issue? If the session is discontinued in the server before deleting the cookie: no

Protocol one SP calls SLO feature at IdP IdP calls all other SPs to perform log out, after all SPs that were used in the current session . The problem is: IdP can only give back SUCCESS or FAILURE to the first SP, not something like “all SPs except x y and z have logged out”.

Hungarian approach is using front channel. Back channel might be more secure.

The application needs to support SLO as well, if it uses a second session.

Usually the application in academia protects only parts of the functionality (lazy authentication). In Gov-Project the whole application is protected by the SP.

There at least needs to be a logout button either at the IdP or at the single applications

Solutions on combining AD Kerberos and SAML: IdP enhancement from SWITCH to reuse windows Kerberos ticket for authentication. Combining Trust between different AD forrests can be an organizational nightmare though. Solution also does not work for home offices.

If you control the Laptop you could a SLO in the browser's toolbar

Reduction of time to live of the assertion is an alternative, but that prevents SSO, if you don't use workarounds again with Cookies or with keep alive pings for renewal of sessions. You need a strong Server at the IdP side for the latter. And if you have long input forms, the user has to hurry up filling them in, before keep alive time is. You need another authentication token (a second cookie) to prevent keep alive by a hacker

You could also temporarily set of SSO for security relevant applications (e.g. enforce authentication flag in Shibboleth SP)

Banks need emergency break: expell a user immediately (= maximum 30 Minutes).is a different use case: SLO not initiated by the user but by the IdP-administrator.
A red button to push by the user, if she has lost a mobile that has logged in.

Is there a conceptional bug in the Hungarian solution, since front channel does not work all the time. That is why it has not been integrated into the shibboleth software.

Rich Clients cannot use front channel any way and might not support java script.

SimpleSAMLPHP claims to provide SLO in front channel.

Now there is a good time to push the new Shib IdP developer to make SLO a high priority.

To sum up:

  • Wait for Sib Idp 2.4.
  • use the front channel solution from Hungary
  • Keep alive solution with a second token