Enhanced Session Assurance with DeviceDNA™

 
casso127
 
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-On
 architecture. Specifically, the Policy Server and the instances of 
CA Access Gateway
 that 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-On
 and 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 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.
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 a basic architectural diagram without Enhanced Session Assurance:
basic SSO deployment without session assurance
basic SSO deployment without session assurance
This architecture uses Web Agents and 
CA Access Gateway
 for 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:
existing SSO for session assurance (AG)
existing SSO for session assurance (AG)
In this architecture, the Policy Server and 
CA Access Gateway
 that 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 Gateway
 CPU 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 Gateway
 with an Existing Policy Server
The following diagram illustrates an architecture that uses a new 
CA Access Gateway
 instance to deploy Enhanced Session Assurance:
New AG for Enhanced Session Assurance
New AG for Enhanced Session Assurance
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 an architecture that uses a new Policy Server and 
CA Access Gateway
 to deploy Enhanced Session Assurance:
New AG and PS for session assurance
New AG and PS for session assurance
In this architecture, a new 
CA Access Gateway
 instance 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.