Managing Session Persistence

Use the Session Persistence page in the Local Management Interface (LMI) to configure the Advanced Access Control and Federation session persistence stores and consumers through their own UI page.

About this task

The following components in the appliance utilize the storage and retrieval of user sessions:
  • Application server HTTP user sessions
  • Authentication service policy state and sessions
  • SAML session footprints
The actual data storage can be configured as one of the following:
  • Distributed Session Cache
  • Distributed Map
The session persistence managed here is for Advanced Access Control and/or Federation only.
Note: Changes made to Managing advanced configuration might affect the settings in session persistence. Each page shows the advanced configuration items that are controlled by the session persistence settings.

Procedure

  1. Select one of the following menu entries for your licensing level:
    • If you are using an Advanced Access Control license, select AAC > Global Settings > Session Persistence.
    • If you are using a Federation license, select Federation > Global Settings > Session Persistence.
    Note: If both licenses are activated, either of the menu items will open the same page.
  2. To manage the user HTTP session storage:
    This might include information related to inflight Authentication Service Requests, inflight Federated SSO flows, or any data stored against the session object in mapping rules.
    1. Select the Data link at the top of the page to ensure that the Data page is open.
    2. Select the User Session tab.
    3. Choose the location for the data tied to the WebSphere Liberty HTTP session that is used by the AAC/Federation runtime by selecting the required radio button:
      • In Memory. When it is configured with "In Memory" persistence, no replication of session data is shared with other servers.
      • Distributed Session Cache
      • Distributed Map
    4. Click Save.
    5. Deploy the changes.
  3. To manage Authentication State Management:
    The authentication service stores policy state and session information between invocations, indexed off the state ID or session ID. Cookies are used to track the state ID unless cookie-less operation is enabled. When cookie-less operation is enabled, the state ID is used as the key into the configured store location.

    If the cookie-less is set to HVDB, the HVDB lifetime should be set to 600 seconds (authsvc.stateMgmt.HVDB.lifetime). This will limit the inactivity lifetime of the session to 600 seconds (10 minutes).

    If cookie-less is enabled, the state ID source should be set to Body Only.(sps.authService.stateIdSource.authsvc, sps.authService.stateIdSource.apiauthsvc)

    These state ID source parameters allow more fine-grained control over how the authentication service sources the state ID. If set to Body and Query, the authentication service continues to accept state ID as a query or body parameter. If set to Body Only, the authentication service only accepts the state ID as a body parameter (POST or PUT).

    1. Select the Data link at the top of the page to ensure that the Data page is open.
    2. Select the Authentication Service tab.
    3. To enable the server side storage of session data, check the Cookie-less check box.
    4. If cookie-less is selected, choose the storage type by selecting the required type from the Store dropdown.
    5. Click Save.
    6. Deploy the changes.
  4. To manage SAML 2.0 session footprint storage:
    1. Select the Data link at the top of the page to ensure that the Data page is open.
    2. Select the SAML 2.0 tab.
    3. Choose the location for the SAML 2.0 footprint data by selecting the required radio button:
      • Distributed Map
      • Distributed Session Cache
    4. Click Save.
    5. Deploy the changes.
  5. To manage the Distributed Session Cache store:
    1. Select the Stores link at the top of the page to ensure that the Stores page is open.
    2. Select the Distributed Session Cache tab.
    3. To use a distributed session cache location on the same server, or as part of a cluster configuration, select the Local to Server/Cluster radio button.
    4. To use a distributed session cache on another server/container, select the External radio button.
      1. To add an external server, click the Add button. Set the hostname, port, and whether to enable SSL and click Save.
      2. To modify an existing server, select the server in the list and click the Edit button. Update the required field(s) and click the Save button.
      3. To delete an existing server, select the server in the list and click the Delete button. Click Delete to confirm the operation.
      4. To change the ordering of the servers use the up and down buttons.
      Note: A maximum of four external servers can be set.
    5. Click Save.
    6. Deploy the changes.
  6. To manage the Distributed Map store:
    1. Select the Stores link at the top of the page to ensure that the Stores page is open.
    2. Select the Distributed Map tab.
    3. To use the high volume database, select the HVDB radio button.
    4. To use Redis, select the Redis radio button.
      1. Select the Redis server connection from the dropdown.
      2. If the Redis server connection does not exist, Click the New button and create the server connection then select it in the dropdown. For details on the creation of the Redis server connection see Server connection properties.
      3. To test the Redis server connection, click Test Connection.
    5. Click Save.
    6. Deploy the changes.