Configuring Client-Based Sessions

Client-based sessions require additional setup in your environment to keep the sessions safe, and to ensure both the browser and the web server where AM runs can manage large cookies. Additionally, some of the AM features cannot be used with client-based sessions. Review the following list before configuring client-based sessions:

Planning for Client-Based Sessions

Ensure the trust store used by AM has the necessary certificates installed:
- A certificate is required for encrypting JWTs containing client-based sessions.
- If you are using RS256 signing, then a certificate is required to sign JWTs. (HMAC signing uses a shared secret.)
The same certificates must be stored on all servers participating in an AM site.
For more information about managing certificates for AM, see Configuring Secrets, Certificates, and Keys.
Ensure that your users' browsers can accommodate larger session cookie sizes required by client-based sessions. For more information about session cookie sizes, see Session Cookies and Session Security.
Ensure that the AM web container can accommodate an HTTP header that is 16K in size or greater. When using Apache Tomcat as the AM web container, configure the server.xml file's maxHttpHeaderSize property to 16384 or higher.
Ensure that your deployment does not require any of the capabilities specified in the list of limitations that apply to client-based sessions.
Limitations When Using Client-Based Sessions
Client-based sessions cannot use the following functionality:
- Session quotas. See "Configuring Session Quotas".
- Session idle timeout. See "Understanding Session Termination".
- Session upgrade with the ForceAuth parameter. See Session Upgrade.
- Cross-domain single sign-on with restricted tokens (Web Agents and Java Agents). See "Enabling Restricted Tokens for CDSSO Session Cookies".
- Both session signing and encryption (Web Agents and Java Agents). See "Client-Based Session Security and Agents".
- Uncompressed sessions (Web Agents and Java Agents). See "Client-Based Session Security and Agents".
- SAML v2.0 single logout using the SOAP binding. See "Session State Considerations".
- SNMP session monitoring. See "SNMP Monitoring for Sessions".
- Session management by using the AM console. See Managing Sessions (UI).
- Session notification. See "Session".

To configure client-based sessions and client-based authentication sessions, see the following procedures:

To Configure Client-Based Authentication Sessions

Important

Configuring storage location for authentication sessions is only supported for authentication trees. Authentication chains always store authentication sessions in AM's memory. For more information, see Introducing Sessions.

In the AM console, go to Realms > Realm Name > Authentication > Settings > Trees.
From the Authentication session state management scheme drop-down list, select JWT.
In the Max duration (minutes) field, enter the maximum life of the authentication session in minutes.
Save your changes.
Navigate to Configure > Authentication > Core > Security.
In the Organization Authentication Signing Secret field, enter a base64-encoded HMAC secret that AM uses to sign the JWT that is passed back and forth between the client and AM during the authentication process. The secret must be at least 128-bits in length.
Save your changes.
Protect your client-based authentication sessions. See "Configuring Client-Based Session Security".

To Configure Client-Based Sessions

In the AM console, go to Realms > Realm Name > Authentication > Settings > General.
Select the Use Client-based Sessions check box.
Save your changes.
Protect your client-based sessions. See "Configuring Client-Based Session Security".
Verify that AM creates a client-based session when non-administrative users authenticate to the realm. Perform the following steps:
1. Authenticate to the AM console as the top-level administrator (by default, the amAdmin user). Note that sessions for the top-level administrator are always stored in the CTS token store.
2. Navigate to Realms > Realm Name > Sessions.
3. Verify that a session is present for the amAdmin user.
4. In your browser, examine the AM cookie, named iPlanetDirectoryPro by default. Copy and paste the cookie's value into a text file and note its size.
5. Start up a private browser session that will not have access to the iPlanetDirectoryPro cookie for the amAdmin user:
  - In Chrome, open an incognito window.
  - In Internet Explorer or Microsoft Edge, start InPrivate browsing.
  - In Firefox, open a new private window.
  - In Safari, open a new private window.
6. Authenticate to AM as a non-administrative user in the realm for which you enabled client-based sessions. Be sure not to authenticate as the amAdmin user this time.
7. In your browser, examine the iPlanetDirectoryPro cookie. Copy and paste the cookie's value into a second text file and note its size. The size of the client-based session cookie's value should be considerably larger than the size of the cookie used by the CTS-based session for the amAdmin user. If the cookie is not larger, you have not enabled client-based sessions correctly.
8. Return to the original browser window in which the AM console appears.
9. Refresh the window containing the Sessions page.
10. Verify that a session still appears for the amAdmin user, but that no session appears for the non-administrative user in the realm with client-based sessions enabled.