Configuration Guides › 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

The following SOA Security Manager features require 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 the consumer (Producer/Identity Provider) retrieves it. A persistent session is required for this process to work.

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

  The single use policy feature prevents assertions (POST binding) from being reused at the relying party to establish a second session. The authentication scheme stores time-based data about the assertion, known as expiry data, in the session store at the relying party. This data helps ensure that the assertion is only used one time. Although a session store is required at the relying party, a persistent session is not required.

• Single logout (SAML 2.0)

  For single logout, the status of the user 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 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, set up the environment as follows:

• Login realm must be configured for persistent sessions for all features except for an 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 verifies 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, share the session store at the asserting and relying party across all Policy Servers in the cluster.

  Sharing the session store verifies 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, share the session store at the relying party across all Policy Servers in the cluster.

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

The following illustration 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.