The Shibboleth V1 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only.
SessionManagement
- Scott Cantor
- Former user (Deleted)
Session Management
Load-balancing requests amongst a number of providers makes management of sessions across a pool of IdPs or SPs and the applications relying on this information more challenging. Refer to the sections on load balancing for more information.
Management of all the sessions maintained by Shibboleth as well as by the applications it protects requires weighing security concerns against usability considerations. Short sessions may require users to reauthenticate repeatedly, with varying amounts of user interaction required depending on what expired. Similarly, long sessions can make session hijacking more likely and extends the window of vulnerability left by users improperly logging out. Lifetimes can be assigned to Shibboleth sessions, assertions, or individual attributes.
General Guidelines
Remember that many of the important session durations are not configured within Shibboleth; in particular, application and login sessions must be properly configured in accordance with security needs.
- Application session length should vary by usage and security requirements, but be shorter than Shibboleth's sessions.
- Shibboleth does provide some limited local logout functionality, which will be made more robust in 2.0. However, applications still must clear their own cookies, which is difficult to rely upon. Logout generally is best done by closing the browser.
- Session duration for the authentication mechanism protecting the IdP should be longer than Shibboleth's sessions.
Configuration
Session configuration for Shibboleth itself is divided between the IdP and SP.
- idp.xml:
<NameMapping handleTTL="seconds"/>: This duration corresponds to the length of the main Shibboleth session at the IdP built using a handle rather than the duration the authentication assertion containing the handle is valid for, which is a fixed 5 minutes. If this expires and an SP needs to make another request using this session at the IdP, such as in delegation or attribute expiration, the full Shibboleth flows will be retriggered. - resolver.xml:
<SimpleAttributeDefinition lifeTime="seconds"/>: Individual attributes can be forced to expire sooner than sessions themselves. Expiration of an attribute needed for access control will trigger a new query for attributes using the existing session handle. Users will notice very little disturbance. The default lifetime is defined inshibboleth.xml. - shibboleth.xml:
<MemorySessionCache defaultLifetime="seconds"/>: If attributes don't have a lifetime specified by an IdP, the SP will use this value for expiration. - shibboleth.xml:
<Sessions lifetime="seconds" timeout="seconds"/>: The Shibboleth SP will allow a user's session with it to persist for a givenlifetimewith action, or fortimeoutwithout activity.