Federation Guides › Partnership Federation Guide › Storing User Session, Assertion, and Expiry Data

Storing User Session, Assertion, and Expiry Data

This section contains the following topics:

Federation Features Requiring the Session Store

Enable the Session Store

Environments that Require a Shared Session Store

Federation Features Requiring the Session Store

The session store holds data for the following federation features:

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

  A SAML assertion and the associated artifact are generated at the asserting party. The artifact identifies the generated assertion. The asserting party returns the artifact to the relying party. The relying party uses the artifact to retrieve the assertion, which the asserting party stores in the session store.

  A persistent session is required for this process to work.

  Note: The SAML POST profile does not store assertions in the session store.

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

  The single use policy feature prevents assertions from being reused at the relying party to establish a second session. The relying party stores time-based data about the assertion, which is known as expiry data, in its session store. Expiry data verifies that the assertion is only used one time.

  A session store is required at the relying party, but a persistent session is not required.

• Single logout (SAML 2.0)

  If single logout is enabled, either partner can stores information about the user session. The session information is kept in the session store. When a single logout request is completed, the session information for the user is removed, invalidating the session.

  A persistent session is required at the Identity Provider and Service Provider.

• Sign-out (WS-Federation)

  If sign-out is enabled, user context information is placed in the session store. This information enables the Policy Server to generate a sign-out request. When a sign-out request is completed, the session information for the user is removed, invalidating the user session.

  A persistent session is required at the Identity Provider and Resource Partner.

• Authentication Session Variables Persistence (all profiles)

  You can select the option Persist Authentication Session Variables when configuring federation at a relying party. This option instructs the Policy Server to save authentication context data in the session store as session variables. The Policy Server has access to these variables for use in authentication decisions.

• Assertion Attributes Persistence (all profiles)

  You can select Persist Attributes as a redirect mode at the relying party. The redirect mode determines how a user is redirected to the target application. This mode instructs the Policy Server to store assertion attributes in the session store so they can be supplied as HTTP header variables.

Enable the session store to hold this type of user session, assertion, and expiry data.

Enable the Session Store

Enable the session store to hold data when using SAML artifact for single sign-on, single logout, and enabling the single use of a policy.

Enable the session store from the Policy Server Management Console.

Follow these steps:

1. Log in to the Policy Server Management Console.
2. Select the Data tab.
3. Select Session Store from the drop-down list in the Database field.
4. Select an available storage type from the drop-down list in the Storage field.
5. Select the Session Store enabled check box.

   If you are going to use persistent sessions in one or more realms, enable the Session Server. When enabled, the Session Server impacts Policy Server performance.

   Note: The Use Policy Store database option is disabled. For performance reasons, the session server cannot be run on the same database as the policy store.

6. Specify Data Source Information appropriate for the chosen storage type.
7. Click OK to save the settings and exit the Console.
8. Stop and restart the Policy Server.

Environments that Require a Shared Session Store

The following features require a shared session store to store SAML assertions and user session information.

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

• Configure the login realm 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, share the session store 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 sign-out, 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.

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 store:

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

• Point all Policy Servers to one session store

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

• Replicate the session store across many session stores.

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