Load Balancer Requirements

Document created by RSA Information Design and Development on Jul 14, 2016Last modified by RSA Information Design and Development on Oct 20, 2017
Version 20Show Document
  • View in full screen mode
  

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 http://<managementIP>:<port>/status/v2/lbstatus, where <managementIP> is the IP address of the identity router management interface, and <port> is either 443 or 8080. If all services are running and the identity router can receive traffic, the servlet returns the status string OK.

Note:  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.

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.

 

Disable Caching

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.

 

Session Persistence

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.

 

SSL Handling

The load balancer must allow users to connect using HTTPS on TCP port 443.

The load balancer can perform SSL termination, which is required when using cookies to manage session persistence. However, if the load balancer decrypts incoming requests on TCP port 443, it must then re-encrypt those requests before directing them to the identity router on port 443. The load balancer can pass encrypted SSL requests directly to the identity router if SSL termination is not required to manage session persistence.

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 on RSA Link at https://community.rsa.com/docs/DOC-59057. You must have an RSA Link account to access the document.

Symmetric Routing

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 proxy interfaces of the identity routers in a cluster.

 

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.

 

 

Previous Topic:Manage Clusters
Next Topic:Add a Cluster
You are here
Table of Contents > Clusters and Backups > Load Balancer Requirements

Attachments

    Outcomes