Simplified SLO (v0.2)

The Austrian Portalverbund never managed to implement a Single Logout (SLO) protocol, mainly because of the known difficulties with usability. However, logout procedures required by security policies need to be obeyed, and closing the browser for logout is difficult to enforce. This was less a problem in the current reverse proxy architecture, but with the migration to the SAML Web SSO it will become an issue.
Related to SLO are 2 other requirements: global session idle timeout and user revocation. All three requirements need solutions that synchronize session state across Identity Providers and Relying Parties in a federation.

This draft proposes a simplified solution based on short-term sessions.

There are following requirements:

  • Logout must be guaranteed for all (active) session in the federation
  • The user must understand the consequences of the logout (i.e. be show the list of used applications)
  • There must not be any lost of data for the user (i.e. POST data needs to be preserved)
  • Optional: Session activity in a service should reset the IdP's idle timeout

The key concept is to require short-term sessions (like 60s session lifetime) from service providers.

Active session scenario:

  • To establish a SP session the standard Web-SSO use case is executed.
  • When the session lifetime (60s) expires, the SP requests an extension of the authN assertion from the IdP using a "custom" back-channel request. This is faster than a front-channel request and avoids the problem of POST data preservation

Simple SLO scenario:

  • Kill the active SP session
  • Redirect to the IdP's SLO-service
  • Have the user to wait up to a minute until the last active assertion will have expired.

There is room for a little improvement:

  1. If the IdP keeps the list of assertions per SP issued during this session, it can be displayed to the user, showing what had expired and what is left to expire. That should keep the user informed about the consequences of the logout.
  2. The user may choose to logout from a single SP using a front-end channel. Failure should be rare, because the number of applications used in the last 30s (average) is usually an odd number less that 2. 

 The sequence diagram shows 5 persistent actors:

AuthN-P: The subject's authentication provider has some "session life" that is outside of the federation's technical control. It might be Kerberos, an unlocked keystore or something else.

IdP: The Identity Provider authenticates the subject using the "previous session" from the AuthN-P.

The service providers use short-term sessions and have to refresh each time after the AuthN assertion times out.

There are temporary session objects. The SLO shows that it kills both the session at SP2 and the IdP. (It could be better to control that from an IdP-generated page).

 

Consequences: A SP must not offer a local-only logout, but only the SLO service.