In an SSO Agent deployment, you can configure a load balancer to direct network traffic evenly among multiple identity routers in a cluster, and to enable other high-availability features such as keychain synchronization. The load balancer must meet the following requirements.
Identity Router Status Checks
The load balancer must be able to determine which identity routers are functioning properly, and which are not. The load balancer can query the operational status of an identity router using the status servlet running on https://<identityrouterIP><:port>/status/v2, where:
<identityrouterIP> is the identity router IP address
<:port> is :9876 for identity routers in the Amazon cloud and not required for on-premises identity routers.
Note: Alternatively, you can use http://<identityrouterIP>:8080/status/v2. Traffic to port 8080 is blocked by the default identity router firewall rules. You must configure a custom firewall rule to access the status servlet on port 8080.
If all services are running and the identity router can receive traffic, the servlet returns the status string OK. As an alternative health check mechanism, the load balancer can monitor the availability of TCP ports 80 and 443 on the identity router. However, monitoring port availability does not guarantee that all necessary identity router services are running.
If High Availability is enabled for the cluster, you can also access the status servlet through the portal interface using the following URLs:
|Portal Interface URL||Returns|
|https://<portal hostname>/status/v2||Full component-level status|
For details on the status servlet report, see Identity Router Status Servlet Report.
You must disable caching on the load balancer. If your load balancer has caching enabled, users may experience intermittent errors when using additional authentication methods.
The load balancer must be able to direct a user's requests to the same identity router for the duration of the user's session, unless that identity router becomes unavailable.
The requests that a user sends on TCP ports 80 (HTTP) or 443 (HTTPS) may be associated with multiple hostnames, for example http://app1.dmz.mydomain.com and https://portal.dmz.mydomain.com. Regardless of protocol or hostname, the load balancer must be able to send each user's requests to the same identity router. Some load balancers achieve this capability through a feature called persistency groups. The load balancer can use source IP-based algorithms as a reliable method to ensure session persistence. However, this may result in uneven load balancing if large numbers of users share the same proxy or gateway, because the users will appear to have the same IP address.
If the load balancer supports Secure Sockets Layer (SSL) termination and re-encryption, it can manage session persistence using cookies. RSA provides the SPBALANCEID cookie, which identity routers set on each user's computer. The cookie contains the value balancer.X.X.X.X where X.X.X.X is the portal interface IP address of the identity router managing the user's sign-in session. When receiving user traffic, the load balancer reads the cookie and directs session traffic to the appropriate identity router. Load balancers can also set their own cookies to manage sessions.
The load balancer must allow users to connect using HTTPS on TCP port 443.
Note: The identity router requires specific requests to be performed using HTTPS on port 443, and redirects those requests to port 443 if the load balancer sends them using HTTP on port 80. To prevent a redirect loop in such cases, the load balancer must be configured to perform SSL re-encryption.
Supported Cipher Suites
If your RSA SecurID Access deployment includes a load balancer or other component that terminates the SSL connection between either the user and the identity router or the identity router and the Cloud Authentication Service, you must ensure that this component is configured to use at least one cipher suite supported by the identity router when reestablishing the SSL connection.
The list of supported cipher suites is available at Security Levels and Identity Router Connection Ciphers.
The load balancer must ensure that portal requests and responses use the same network path.
To provide symmetric routing capability, the load balancer can perform Source Network Address Translation (SNAT). If the load balancer performs SNAT, the X-Forwarded-For header must be set to inform the identity router of the original (pre-SNAT) IP address of the client . The X-Forwarded-For header name is case sensitive. To inject the header, the load balancer may need to perform SSL termination and re-encryption.
If the load balancer performs SSL termination and re-encryption, then all TCP requests sent to the identity router originate from the load balancer, and no additional configuration is required to support symmetric routing.
As an alternative method for symmetric routing, the load balancer can act as the default gateway for the network interfaces of the identity routers in a cluster. For on-premises identity routers, the load balancer should act as the gateway for the proxy interface.
Replace X-Forward-For Headers
In user requests, the X-Forward-For headers can easily be spoofed by malicious users. Therefore, it is important that you configure the load balancer and proxy servers to replace these headers with the true client IP address before they send these requests to the identity router.
Compatible Load Balancers
You can configure the following load balancing products for use with RSA SecurID Access:
- CISCO ACE family
- F5 Big-IP family
- Citrix Netscaler
- Barracuda Load Balancers
Global Server Load Balancers
In addition to standard load balancers that direct traffic within clusters, you can also configure a Global Server Load Balancer (GSLB) to direct network traffic among load balancers for clusters at different geographic locations. The GSLB must be able to do the following:
- Monitor cluster status. For example, if your standard load balancers can report cluster status, the GSLB can query the standard load balancers to determine when to direct traffic to each cluster.
- Direct a user's requests to the same cluster for the duration of the user's session, unless that cluster becomes unavailable.