Session Management in Shibboleth

Federated identity involves many different sessions that are established between the user and services. Most of these sessions are persisted through cookies, which are associated with additional session information at the provider or application.

• Sessions at the identity provider are used to provide single sign-on, removing the need for additional authentication. An IdP can also cache information for speed and track sessions at service providers for logout.
• Sessions at the discovery service can automate IdP selection, removing the need for additional user interaction.
• Sessions at the service provider persist a login across individual HTTP requests from a single client. They can be maintained on a coarse or fine grain, with individual sessions for each application.
• Each application can (and usually does) maintain distinct sessions with the browser.

All these sessions are pretty much independent and distinct: any session can exist with or without any other session, and the expiration of any one session does not imply the expiration of any other session. Some sessions can be associated with each other through use of common identifiers. This makes single log-out a very difficult problem.

A session established by the application may persist well beyond the Shibboleth session. Unless the application is enhanced, logouts from the application often will not terminate a Shibboleth session initiated to access the resource. Unless configured and designed to do so, the converse is true as well: logging out of Shibboleth will not remove application sessions. The duration of sessions should be coordinated when possible, since their expiration affects the user experience and can cause confusion. This should be weighed against the vulnerability of impersonation, malicious or otherwise, due usually to user negligence.