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.
sm1252sp1
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.

The initial fingerprinting and subsequent rechecks increase demands on the 
CA Single Sign-On
 architecture. Specifically, the Policy Server and the instances of 
CA Access Gateway
 that run Enhanced Session Assurance are impacted. The time to authenticate a user increases, as does 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-On
and running Enhanced Session Assurance is higher.
The application that drives the DeviceDNA checks is hosted on by the 
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 Gateway
 performance 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.
This topic explains the following:
3
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 New
    CA Access Gateway
     and 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 an abbreviated, basic 
CA Single Sign-On
 architectural diagram that does not use Enhanced Session Assurance:
Basic Service Assurance Architecture
Basic Service Assurance Architecture
This architecture uses Web Agents and 
CA Access Gateway
 for proxying to other web applications.
Architecture 1: Use Existing Components
The following diagram illustrates a 
CA Single Sign-On
 architecture that uses existing components to deploy Enhanced Session Assurance:
Session Assurance using existing architecture
Session Assurance using existing architecture
In this architecture, the existing Policy Server and 
CA Access Gateway
 that are highlighted in 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 Gateway
 CPU usage increases. If the load increases to the point at which the component 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 Gateway
  with an Existing Policy Server
The following diagram illustrates a 
CA Single Sign-On
 architecture that uses a new 
CA Access Gateway
 instance to deploy Enhanced Session Assurance:
session assurance with newSPS existingPS
session assurance with newSPS existingPS
In this architecture, a new 
CA Access Gateway
 is 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 Gateway
 instances that proxy requests to back-end web servers. By sharing Policy Server across the 
CA Access Gateway
 instance 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 a possible 
CA Single Sign-On
 architecture that uses a new Policy Server and 
CA Access Gateway
 to deploy Enhanced Session Assurance:
Session Assurance using an existing Policy Server
Session Assurance using an existing Policy Server
In this architecture, a new 
CA Access Gateway
 instance is deployed specifically for hosting Enhanced Session Assurance. The new 
CA Access Gateway
 communicates with a new Policy Server. Though this architecture increases hardware in the environment, it keeps the existing Policy Server load and performance as close to the basic architecture as possible.
This architecture is recommended for large organizations that want to quickly rollout Enhanced Session Assurance. This helps in minimizing the chances of Enhanced Session Assurance increasing the CPU utilization or monopolizing threads that are needed for the general processing of requests.