CTS-Based Sessions

CTS-based sessions reside in the CTS token store and can be cached in memory on one or more AM servers to improve system performance [1] . If the session request is redirected to an AM server that does not have the session cached, that server must retrieve the session from the CTS token store.

AM sends a reference to the session to the client, but the reference does not contain any of the session state information. AM can modify a session during its lifetime without changing the client's reference to the session.

  • CTS-Based Authentication Sessions Specifics

    CTS-based authentication sessions are supported for authentication trees only.

    During authentication, the session reference is returned to the client after a call to the authenticate endpoint and stored in the authId object of the JSON response.

    AM maintains the authenticating user's session in the CTS token store. After the authentication flow has completed, if the realm to which the user has authenticated is configured for client-based sessions, AM returns session state to the client and deletes the CTS-based session.

    Authentication session whitelisting is an optional feature that maintains a list of in-progress authentication sessions and their progress in the authentication flow to protect against replay attacks. For more information, see "Configuring Authentication Session Whitelisting".

  • CTS-Based Sessions

    Once the user is authenticated, the session reference is known as an SSO token. For browser clients, AM sets a cookie in the browser that contains the session reference. For REST clients, AM returns the session reference in response to calls to the authentication endpoint.

    For more information about session cookies, see Session Cookies and Session Security.

Related information:


[1] For information about configuring AM with sticky load balancing, see Load Balancers.

Read a different version of :