Session store is required to persist user session data, authentication context data and other contextual attributes in both federation and non-federation flows. This not only provides enhanced session security but can also be applied across applications for an improved personalized experience for the end user.
Let’s look at some of these flows where session store deployment is required, to understand the benefits in more detail.
- Accomplishing Single Logout flows in SAML 2.0 and Sign-Out flows in WS-Fed. If single logout is enabled, CA SSO stores information about the user session in the session store. When a single logout request is completed, the session information for the user is removed, invalidating the session. The SLO flows help mitigate the risk of orphaned SSO sessions and hence result in higher security.
- Accomplishing Single Logout (SLO) flows for non-federation flows as well, by configuring a realm to have persistent sessions and short session validation period. After a Logoff, the session is removed from the session store, so if a bad actor attempts to replay a SMSESSION cookie after the validation period, the web agent will contact the policy server and find that the session is invalid and will reject the user session. So, it helps mitigate the risk of session replay and orphaned SSO sessions.
3. All the OpenID Connect flows that are implemented in CA Single Sign-On as an OpenID Connect Provider require the use of session store, to store OIDC specific tokens and session information. OpenID Connect is a modern identity protocol built on top of OAuth 2. It is an emerging standard for Federation and is already in wide use in Internet SSO.
4. In HTTP-POST single use policy flows (SAML 2.0 and WS-Federation), the relying party stores time-based data about the assertion, which is known as expiry data, in its session store. Expiry data verifies that the assertion is only used one time and hence prevents assertions from being reused at the relying party to establish a second session, in case of stolen assertions.
5. Enables implementation of HTTP-Artifact Binding in SAML flows. A SAML assertion and the associated artifact are generated at the Identity Provider (IDP) and stored in session store. The artifact identifies the generated assertion. The IDP returns the artifact to the relying party. The relying party uses the artifact to retrieve the assertion, which the IDP stores in the session store. HTTP-Artifact Binding flow is designed to avoid Man-In-The-Middle attacks.
6. CA Single Sign-On cookie provider can be configured to store the session in a centralized session store and then pass a one-time reference to the stored session on the query string. Then the application requesting the session will have the session provided by the policy server it is communicating with instead of, directly reading it from the query string. This results in higher security, as it helps mitigate any attacker from gaining access to session data from query string directly, which is where the session data is stored if there was no session store deployed.
7. CA SSO utilizes a patented technology called the “Enhanced session assurance with Device DNA™”, to help mitigate the risk of session replay attacks. This capability involves uniquely fingerprinting a device in a continuous fashion, and to compare the same with the fingerprint taken at the time of login, to identify compromised sessions. Session store is required to deploy this feature in a CA Single Sign-On deployment, for storing device context and other key session information.
8. Persisting authentication context in a session store is very useful to determine the level of confidence of the transactions whether it is federation (e.g. SAML 2.0) or non- federation flows (e.g. X.509 Certificate Authentication flow)
9. Persisting user and session attributes is an important building block of delivering personalized experiences to your end users. This is because persisting user context not only is important for making informed entitlement decisions but also important to understand the end users. It is possible to apply fine grained policies on the stored user context and customize the flows to build the most personalized experience.
CA Single Sign-On supports data stores from several vendors for use as a session store. CA Directory is a battle-tested directory server that provides the scalability and reliability, for use as session store with CA Single Sign-On. And the best part is…that CA Directory license is included to all CA Single Sign-On customers for use as session store, policy and key store, free of charge!
For more details on session store deployment, please refer to technical documentation or get in touch with Support.