Enhanced Session Assurance with DeviceDNA™
The Enhanced Session Assurance feature prevents session hijacking and replay. When you log in, a DeviceDNA™ verification is performed to fingerprint the end-user device. The device is finger printed every five minutes by default. The verification compares the new fingerprint against the original fingerprint that was taken during login.
Note:The video references the product name as CA SiteMinder, the former name of
CA Single Sign-On(CA SSO).
The initial fingerprinting and subsequent rechecks increase demands on the
CA Single Sign-Onarchitecture. Specifically, the Policy Server and the instances of
CA Access Gatewaythat run Enhanced Session Assurance are impacted. There is an increase in the time to authenticate a user and the time to authorize access to a resource when a revalidation of the fingerprint is required. The amount of extra latency during authentication depends on several parameters such as, but not limited to, network connection speeds, server capacity, and the end-user device. This latency increase is due to extra redirections and processing time for the DeviceDNA™ collection and calculations. Also, resource use such as CPU utilization consumption for systems hosting the
CA Single Sign-Onand running Enhanced Session Assurance is higher.
The application that drives the DeviceDNA checks is hosted by
CA Access Gateway. This proxy server can perform the standard functions such as web proxy or SAML federation functions or it can be a separate stand-alone instance that is dedicated to servicing the Enhanced Session Assurance transactions. The
CA Access Gatewayperformance is also dependent on a number of parameters such as, but not limited to, authentication and authorization transactions per second, the ratio of authentications to authorizations within the environment, the length of user sessions, and the frequency of revalidations.
The best practice is to install Enhanced Session Assurance in a development environment and test its impact on that environment. To test the feature, enable it for different applications or realms gradually while measuring its impact on performance.
Enhanced Session Assurance does not work with SSO Security Zones.
Architecture Options and Performance
There are three architectures that you can use to deploy Enhanced Session Assurance:
- Architecture 1: Use Existing Components
- Architecture 2: Use a NewCA Access Gatewayand an Existing Policy Server
- Architecture 3: Full Separation of the Session Assurance Components
Review the choices to determine how to minimize the performance impact on existing applications in your environment that do not use this feature.
The following diagram illustrates a basic architectural diagram without Enhanced Session Assurance:
This architecture uses Web Agents and
CA Access Gatewayfor proxying to other web applications.
Architecture 1: Use Existing Components
The following diagram illustrates an architecture that uses existing components to deploy Enhanced Session Assurance:
In this architecture, the Policy Server and
CA Access Gatewaythat are highlighted in white boxes are used for Enhanced Session Assurance. No additional hardware is required to deploy the feature. However, as the Enhanced Session Assurance load increases, the Policy Server and
CA Access GatewayCPU usage increases. If the load increases to the point where the components threads are fully utilized or the CPU cannot keep up with load, all the transactions are negatively impacted. Even transactions that are not configured to use Enhanced Session Assurance are impacted.
Architecture 2: Use a New
CA Access Gatewaywith an Existing Policy Server
The following diagram illustrates an architecture that uses a new
CA Access Gatewayinstance to deploy Enhanced Session Assurance:
In this architecture, a new
CA Access Gatewayis introduced, as highlighted in green. This proxy server fulfills all Enhanced Session Assurance tasks to avoid increased CPU utilization or a performance decrease of the other
CA Access Gatewayinstances that proxy requests to back-end web servers. By sharing Policy Server across the
CA Access Gatewayinstance and the other agents and instances, the Policy Server utilization demand can increase beyond its capacity. If this increase occurs, all the transactions from applications and agents are affected.
Architecture 3: Full Separation of the Session Assurance Components
The following diagram illustrates an architecture that uses a new Policy Server and
CA Access Gatewayto deploy Enhanced Session Assurance:
In this architecture, a new
CA Access Gatewayinstance is deployed specifically for hosting Enhanced Session Assurance. The new instance communicates with a new Policy Server. This architecture increases hardware in the environment, but it keeps the existing Policy Server load and performance close to the basic architecture.
This architecture is recommended for large organizations that want to implement Enhanced Session Assurance quickly. This architecture helps minimize the chances of Enhanced Session Assurance increasing the CPU utilization and monopolizing threads that are needed for the general requests processing.