Access Management 7.3.1

Choose where to store sessions

You can configure authentication session storage location independently from session storage location. For example, you could configure the same realm for client-side authentication sessions and server-side sessions if it suits your environment.

AM stores server-side sessions in the CTS token store and caches sessions in server memory. If a server with cached sessions fails, or if the load balancer in front of AM servers directs a request to a server that does not have the user’s session cached, the AM server retrieves the session from the CTS token store, incurring performance overhead.

Choosing where to store sessions is an important decision you must make by realm. Consider the information in the following tables before configuring sessions:

Advantages of server-side sessions
Advantage Applies to authentication sessions? Applies to sessions?

Full feature support

Server-side sessions support all AM features, such as CDSSO and quotas. Client-side sessions do not. For information about restrictions on AM usage with client-side sessions, see Limitations of client-side sessions.

This advantage does not apply to authentication sessions, since they do not provide features.

Session information is not resident in browser cookies

With server-side sessions, all the information about the session resides in CTS and might be cached on one or more AM servers. With client-side sessions, session information is held in browser cookies. This information could be very long-lived.

Advantages of client-side sessions
Advantage Applies to authentication sessions? Applies to sessions?

Unlimited horizontal scalability for session infrastructure

Client-side sessions provides unlimited horizontal scalability for your sessions by storing the session state on the client as a signed and encrypted JWT.

Overall performance on hosts using client-side sessions can be easily improved by adding more hosts to the AM deployment.

Replication-free deployments

Global deployments may struggle to keep their CTS token store replication in sync when distances are long and updates are frequent.

Client-side sessions are not constrained by the replication speed of the CTS token store. Therefore, client-side sessions are usually more suitable for deployments where a session can be serviced at any time by any server.

Advantages of in-memory sessions
Advantage Applies to Authentication Sessions? Applies to Sessions?

Faster performance with equivalent host

AM servers configured for in-memory authentication sessions can validate more sessions per second per host than those configured for client-side or server-side authentication sessions.

Session information is not resident in browser cookies

Authentication session information resides in AM’s memory and it is not accessible to users. With client-side sessions, authentication session information is held in browser cookies.

Impact of storage location for authentication sessions
Server-side authentication sessions Client-side authentication sessions In-memory authentication sessions

Authentication method

Authentication trees.

Authentication trees.

Authentication trees and authentication chains.

Session location

Authoritative source: CTS token store. Sessions might also be cached in AM’s memory for improved performance.

On the client.

In AM server’s memory.

Load balancer requirements

None. Session stickiness recommended for performance.

None. Session stickiness recommended for performance.

Session stickiness.

Core token service usage

Authoritative source for user sessions. Session allowlisting, when enabled.

Session allowlisting, when enabled.

None.

Uninterrupted session availability

No special configuration required.

No special configuration required.

Not available.

Session security

Sessions reside in the CTS token store, and are not accessible to users.

Sessions reside on the client and should be signed and encrypted.

Sessions reside in AM’s memory, and are not accessible to users.

Impact of storage location for sessions
Server-side Sessions Client-side Sessions

Hardware

Higher I/O and memory consumption.

Higher CPU consumption.

Logical hosts

Variable or large number of hosts.

Variable or large number of hosts.

Session monitoring

Available.

Not available.

Session location

Authoritative source: CTS token store. Sessions might also be cached in AM’s memory for improved performance.

In a cookie in the client.

Load balancer requirements

None. Session stickiness recommended for performance.

None. Session stickiness recommended for performance.

Uninterrupted session availability

No special configuration required.

No special configuration required.

Core token service usage

Authoritative source for user sessions.

Provides session denylisting for logged out sessions.

Core token service demand

Heavier.

Lighter.

Session security

Sessions reside in the CTS token store, and are not accessible to users.

Sessions should be signed and encrypted.(1)

Cross-domain single sign-on support

All AM capabilities supported.

Web agents and Java agents: Supported without restricted tokens.

(1) Web agents and Java agents support either signing or encrypting client-side sessions, but not both. For more information, see Client-side session security and agents.

Copyright © 2010-2024 ForgeRock, all rights reserved.