A cluster is a group of one or more identity routers. In an SSO Agent deployment, you can group multiple identity routers into clusters to enable high availability features, such as session replication, load balancing, keychain synchronization, and backup.
Every identity router must be part of a cluster. If no clusters exist the first time you add an identity router using the Cloud Administration Console, RSA SecurID Access automatically creates a default cluster and adds the identity router to the cluster. You can edit the name and other parameters for the default cluster or any cluster that you add using the Cloud Administration Console. You can add subsequent identity routers to the default cluster, or to another cluster that you added manually.
Cluster Status in SSO Agent Deployments
In an SSO Agent deployment, clusters automatically transition between two operational states, quorum and read-only, depending on how many identity routers in the cluster are fully functioning.
A cluster is in quorum when more than 50% of its identity routers can communicate with each other. Users can authenticate through the cluster. Users who authenticate to HTTP Federation applications can create or modify user profile data (application sign-in credentials).
A cluster is read-only when 50% or more of its identity routers do not allow users who access HTTP Federation applications to create or change user profile data. These users receive an error message if they try to set application-specific sign-in credentials. Users can still authenticate to all identity routers in the cluster and access HTTP Federation applications.
Note: Read-only status does not affect your ability to administer the cluster or make configuration changes. You can still use the Cloud Administration Console to update your deployment when a cluster is read-only.
The examples in following table illustrate how quorums are calculated.
|Total Identity Routers in Cluster||Identity Routers Down||Cluster Status|
|2||0||Quorum (fully operational)|
|3||0||Quorum (fully operational)|
|3||1||Quorum (fully operational)|
You can configure a third-party monitoring service to query any identity router in the cluster using the status servlet running on http://<identityrouterIP>:<port>/status/v2/lbstatus, where <identityrouterIP> is the IP address of the identity router, and <port> is the port number. For identity routers in the Amazon cloud, use the private IP address and port 9786. For on-premises identity routers, use the management interface IP address and port 443 or 8080. The status servlet reports ClusterStatus.readOnly=false for quorum, and ClusterStatus.readOnly=true for read-only.
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.
You can achieve optimal balance between resource usage and fault tolerance by configuring clusters with odd numbers of identity routers.
SSO Agent High Availability Features
- Load balancing
- Keychain synchronization
- Intracluster session replication
- Multicluster deployments
- Disaster recovery
- Geographically Distributed High Availability (GDHA)
Load balancing is a high availability feature that improves identity router response time and reliability during periods of heavy network traffic, when large numbers of users attempt authentication simultaneously. A load balancer directs network traffic among multiple identity routers in a cluster. In a load-balanced cluster, user network traffic does not reach the identity routers directly by their individual host names. Instead, the traffic reaches the load balancer by its DNS name. The load balancer forwards the requests based on the available capacity of each identity router. Load balancing is a prerequisite for all other high availability features. For more information, see:
SSO Agent Keychain Synchronization
In an SSO Agent deployment, keychain synchronization is a high availability feature that enables sharing of stored application-specific user credentials among the identity routers in a cluster, or from one cluster to another. If an identity router or cluster becomes unavailable for any reason while keychain synchronization is enabled, users can still authenticate using stored credentials on a separate synchronized identity router or cluster. Keychains are synchronized within a cluster automatically when you enable high availability for the cluster, and each time changes are published within the cluster. You configure synchronization between clusters manually using cluster relationships.
For more information, see Cluster Relationships.
SSO Agent Intracluster Session Replication
In an SSO Agent deployment, intracluster session replication is a high availability feature that enables sharing of user authentication sessions among the identity routers in a cluster. If an identity router becomes unavailable for any reason while session replication is enabled, users who authenticated to that identity router can continue to interact with web applications through other identity routers in the cluster automatically, without authenticating again. Session replication requires frequent communication among identity routers within a cluster, which can reduce performance in high-traffic environments. When session replication is disabled, users are required to re-authenticate in a failover scenario. RSA SecurID Access does not support session replication between clusters.
SSO Agent Multicluster Deployments
RSA SecurID Access supports SSO Agent deployments that use multiple clusters to provide the following high availability features.
- Disaster Recovery - An active cluster in a local data center manages authentication under normal circumstances. You can activate a standby cluster in a remote data center if the primary cluster fails.
- Geographically Distributed High Availability (GDHA) - Multiple clusters in separate geographic locations manage authentication. A Global Server Load Balancer (GSLB) directs user traffic to the appropriate cluster based on availability and proximity.
Note: In a multicluster deployment, the load balancers for all clusters must use the same DNS name. DNS directs user traffic to the appropriate cluster.