Implementation Guide › Architectural Considerations › Enhanced Session Assurance Architecture and Performance Considerations

Enhanced Session Assurance Architecture and Performance Considerations

The Enhanced Session Assurance feature prevents session hijacking and replay. When you log in, a DeviceDNA™ check is performed to fingerprint the end-user device. The device is validated by fingerprinting every 5 minutes by default and comparing the new fingerprint against the original fingerprint that is taken during the log in.

The work to perform the initial fingerprinting and subsequent re-checks will increase demands on the CA SiteMinder® architecture. Specifically, the CA SiteMinder® Policy Server and the instances of CA SiteMinder® SPS that run the Enhanced Session Assurance flow application are impacted. The time to authenticate a user increases, as will the time to authorize access to a resource when a re-validation of the fingerprint is required. The actual amount of additional latency during authentication depends on a number of parameters such as, but not limited to, network connection speeds, server capacity, and the end user’s device. Internal testing has shown that authentication latency for an application configured with Enhanced Session Assurance may increase by 60%. This is due to additional redirections and processing time for the DeviceDNA™ collection and calculations. The actual percentage increase in each environment varies depending on the current authentication latency, the network, and speed of the computer that is accessing the resource. Additionally, resource (For example, CPU utilization) consumption for systems hosting the CA SiteMinder® family components that participate in an Enhanced Session Assurance transaction is higher if the transaction did not use Enhanced Session Assurance.

The application that drives the DeviceDNA checks is hosted on a CA SiteMinder® SPS instance. The instance can be a CA SiteMinder® SPS instance that performs the standard CA SiteMinder® SPS functions, such as web proxy or SAML federation functions or it can be a separate stand-alone CA SiteMinder® SPS instance that is dedicated to servicing the Enhanced Session Assurance transactions. Performance of the CA SiteMinder® SPS platform 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 re-validations.

This section describes the different architectures that can be used for deploying CA SiteMinder® Enhanced Session Assurance and outlines choices to minimize the performance impact on existing CA SiteMinder® applications that do not use the feature in your environment.

Regardless of the architecture you choose to deploy, it is very important to introduce Enhanced Session Assurance gradually. The best practice is to install it in a development environment and test its impact on that environment by enabling it for different applications or realms gradually while measuring its impact on performance.

Basic Architecture

The following diagram illustrates an abbreviated, basic CA SiteMinder® architectural diagram that does not use Enhanced Session Assurance:

This architecture uses both Web Agents and CA SiteMinder® SPS for proxying to other web applications.

Possible Architecture 1–Use Existing Components

The following diagram illustrates a CA SiteMinder® architecture that uses existing components to deploy Enhanced Session Assurance:

In this architecture, Policy Server and CA SiteMinder® SPS that are highlighted in green can be used for Enhanced Session Assurance. Using the existing Policy Server and CA SiteMinder® SPS means that no additional hardware is needed to deploy the feature. However, in this architecture, as the Enhanced Session Assurance load increases, the CPU utilization of Policy Server and CA SiteMinder® SPS increases. If the load increases until either component’s threads are fully utilized or the CPU cannot keep up with load, all the CA SiteMinder® transactions, regardless of whether they are configured to use Enhanced Session Assurance or not, will be negatively impacted.

Possible Architecture 2–Use Existing Policy Server

The following diagram illustrates a CA SiteMinder® architecture that uses a new CA SiteMinder® SPS instance to deploy Enhanced Session Assurance:

In this architecture, a new CA SiteMinder® SPS is introduced as highlighted in green. This CA SiteMinder® SPS fulfills all Enhanced Session Assurance tasks to avoid increased CPU utilization or a performance decrease of the other CA SiteMinder® SPS instance that is used to proxy requests to back-end webservers. However, by sharing the same Policy Server across both the CA SiteMinder® SPS instance running the Enhanced Session Assurance flow application, and the other agents and CA SiteMinder® SPS instances, if the Policy Server utilization demand is increased beyond its capacity, then all the CA SiteMinder® transactions from applications and agents will be affected.

Possible Architecture 3–Full Separation of the Session Assurance Components

The following diagram illustrates a possible CA SiteMinder® architecture that uses a new Policy Server and CA SiteMinder® SPS to deploy Enhanced Session Assurance:

In this architecture, a new CA SiteMinder® SPS instance is deployed specifically for hosting Enhanced Session Assurance. The new CA SiteMinder® SPS 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.