CTS overview
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 server-side 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 server-side 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:
-
Server-side sessions and server-side authentications sessions
-
Session denylist (if enabled for client-side sessions)
-
Authentication session allowlist (if enabled for client-side sessions)
-
SAML v2.0-related data (if enabled for Security Token Service token validation and cancellation)
-
OAuth 2.0 and UMA 2.0 server-side tokens, and OAuth 2.0 client-side token denylist
-
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 in high-load deployments, configure an additional DS service, separate from your configuration store, to isolate session and token information.
CTS configuration recommendations
CTS helps your deployment avoid single points of failure by providing high availability to sessions and tokens stored in its token store.
For high-volume, demanding deployments, consider the following recommendations:
-
Consider separate CTS storage 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.
-
Isolate different stores for high volumes. 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.
For high-volume deployments, consider putting CTS data in a separate DS data store and using different tuning and storage settings
-
Tune DS servers. For high performance, properly size and tune DS servers for your external CTS store.
In addition, you can enable token compression as discussed in Manage CTS tokens. When enabled, token compression reduces load requirements on the network connection between token stores in exchange for processing time-compressing tokens.
-
Limit DS replication traffic over slow links. DS servers replicate CTS data transmitted from AM servers. For each change to a CTS token, DS replication replays the change on all DS servers in the CTS data store. The volume of replication traffic is potentially problematic over slow links.
For high volumes when low latency is required, consider limiting the replication traffic as described in 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.