The Core Token Service
AM's Core Token Service (CTS) provides generalized, persistent, and highly available storage for sessions and tokens used by AM. AM uses CTS as the authoritative source for CTS-based sessions and caches these sessions in its memory heap to improve performance.[1]
CTS supports session high availability, which lets AM manage a session as long as one of the AM servers in a clustered deployment is available. After a user has successfully authenticated, AM creates a CTS-based session. Any AM instance that is configured to use the same CTS can retrieve the session and allow access to it. The user does not need to log in again unless the entire deployment goes down.[2]
CTS provides storage for the following:
CTS-based sessions and CTS-based authentications sessions
Session blacklist (if enabled for client-based sessions)
Authentication session whitelist (if enabled for client-based sessions)
SAML v2.0-related data (if enabled for Security Token Service token validation and cancellation)
OAuth 2.0 and UMA 2.0 CTS-based tokens, and OAuth 2.0 client-based token blacklist
Push notification data during authentication
Site-wide notification, such as log out or session termination notifications.
The CTS token store is created at installation time in the external configuration store.
In general, the Core Token Service causes more volatile replication traffic due to the possibility of short-lived entries compared to regular configuration data. To handle the data volatility, ForgeRock recommends that you configure an additional DS server, separate from your configuration store, to isolate session and token information. For more information, see "General Recommendations for CTS Configuration".
General Recommendations for CTS Configuration
CTS helps your deployment avoid single points of failure by providing high availability to sessions and tokens stored in its token store. To reduce the impact of any given failure, consider the following recommendations:
Configure Separate CTS Stores for High Volumes. If you require a higher-level performance threshold, you may want to move the CTS token storage to one or more dedicated systems rather than sharing your configuration store, as CTS generally causes much more replication traffic than less volatile configuration data. The CTS token store is the primary source for session tokens and will experience both high read and write activity depending on session usage. Dedicated external CTS stores provide an extra level of control over the amount of global replication that is occurring.
Isolate the Different Stores. CTS entries are large, around 5KB, but are short-lived, whereas configuration data is static and long-lived. User entries are more dynamic than configuration data but much less volatile than CTS data. Therefore, isolating the user, configuration, and CTS data from AM into separate stores allow for different tuning and storage settings per token store type.
Isolate the Datastores
Properly Tune Your DS Servers. To improve performance, ensure that you have properly-sized directory servers for your external CTS stores. In addition, you can enable token compression as discussed in Managing CTS Tokens. When enabled, token compression reduces load requirements on the network connection between token stores in exchange for processing time-compressing tokens.
Consider Dedicated Replication Servers. Once configured, the DS server replicates CTS data transmitted from AM servers to connected DS servers. The amount of replication traffic can be significant, especially if replication proceeds over a WAN. You can limit this replication traffic by separating DS instances into directory and replication servers as seen in "Core Token Service For Global Session Failover". For more information on how this is done with DS, see the DS documentation on Standalone Servers.
[1] Prior to AM 5, the authoritative source for sessions not stored in the client was the memory heap of AM's web container.
[2] Prior to AM 5, session high availability, formerly referred to as session failover, was optional. Starting with AM 5, session high availability is the default behavior in AM and cannot be disabled.