Federation Security Services Guide › Storing User Session, Assertion, and Expiry Data › Environments that Require a Shared Session Store

Environments that Require a Shared Session Store

SiteMinder's implementation of the following features requires a session store to store SAML assertions and user session information:

• HTTP-Artifact single sign-on (SAML 1.x or 2.x)

  The assertion is stored in the session store until it is retrieved by the consumer (Producer/Identity Provider). A persistent session is required for this to work.

• HTTP-POST single use policy (SAML 2.0 and WS-Federation)

  The single use policy feature prevents SAML 2.0 assertions that arrive via the POST binding from being re-used at a Service Provider to establish a second session. Time-based data about the assertion, known as expiry data, is stored by the authentication scheme in the session store at the Service Provider/Resource Partner. This data ensures that a SAML 2.0 POST or WS-Federation assertion is only used a single time. Although a session store is required at the Service Provider/Resource Partner, a persistent session is not required.

• Single logout (SAML 2.0)

  For single logout, the status of the user's session in the session store must be changed to invalidate the session. A persistent session is required at the Identity Provider and Service Provider.

• Signout (WS-Federation)

  For WS-Federation signout, the status of the user's session in the session store must be changed to invalidate the session. A persistent session is required at the Account Partner and Resource Partner.

To implement these features across a clustered Policy Server environment, you must set up the environment as follows:

• Log-in realm must be configured for persistent sessions for all features except for a HTTP-POST single use policy

  Persistent sessions are part of the realm configuration.

• For HTTP-Artifact single sign-on, the session store must be shared at the Producer/Identity Provider site across all Policy Servers in the cluster.

  Sharing the session store ensures that all Policy Servers have access to assertions when each one receives a request for an assertion.

• For SAML 2.0 single logout, and WS-Federation signout, the session store must be shared at the Identity Provider/Account Partner site and the Service Provider/Resource Partner site across all Policy Servers in the cluster.

  Sharing the session store ensures that all Policy Servers have access to user session data when each one receives a request for a session logout.

• For the HTTP-POST and WS-Federation single use policy feature, the session store must be shared at the consumer site (Service Provider/Resource Partner) across all Policy Servers in the cluster.

Note: All Policy Servers that can generate or consume assertions or process a persistent SMSESSION cookie need to be able to contact the common session store. For example, if a user logs into example.com and gets a persistent session cookie for that domain, every single Policy Server that is handling requests for example.com must be able to check that the session is still valid.

The following figure shows a Policy Server cluster communicating with one session server:

To share a session store, use one of the following methods:

• Point all Policy Servers to one session server

  In the Policy Server Management Console, configure the Policy Server to use the designated session server.

• Replicate the session store across many session servers

  For instructions on replicating a database, use the documentation for your database.