You can group multiple identity routers into clusters to enable high availability features, such as session replication, load balancing, and keychain synchronization.
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. The following features are also managed within clusters:
Built-in RADIUS server to enable RSA SecurID Access authentication for users who access protected networks through RADIUS-capable devices.
SSO Agent to enable RSA SecurID Access as your company's single sign-on (SSO) service.
Note: Cluster features related to high availability and SSO are not supported for identity routers that are embedded in RSA Authentication Manager. These identity routers are also not included in quorum calculations.
For more information, see:
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. For more information, see:
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 following example illustrates 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 https://<identityroutermanagementIP><:port>/status/v2, where:
<identityroutermanagementIP> is the identity router management IP address
<:port> is :9876 for identity routers in the Amazon cloud and not required for on-premises identity routers.
The status servlet reports ClusterStatus.readOnly=false for quorum, and ClusterStatus.readOnly=true for read-only.
Note: Alternatively, you can use http://<identityroutermanagementIP>: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 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|
You can achieve optimal balance between resource usage and fault tolerance by configuring clusters with odd numbers of identity routers.
For details on the servlet status report, see Identity Router Status Servlet Report.
In an SSO Agent deployment, the term "high availability" represents a set of features designed to improve performance, reduce downtime, and resist hardware or network failure by enabling identity routers and clusters to share their status, workload, and user information. You can enable or disable high availability functionality when you add or edit each cluster. You can configure clusters to provide the following high availability features:
Load balancing 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 Configure High Availability for Cloud Administration Console Deployments
You can add a cluster without enabling high availability, but the capabilities of the cluster will be severely restricted. If a cluster contains only one identity router, it is not necessary to enable high availability, because a single identity router cannot support high availability features.
Note: You must enable high availability if you deploy FIDO authenticators and the cluster contains more than one identity router.
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.
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.
RSA SecurID Access supports SSO Agent deployments that use multiple clusters to provide the following high availability features.
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.
Note: Enabling RADIUS for a cluster automatically opens RADIUS UDP port 1812 in the firewall settings for all identity routers in the cluster.
(Optional) If you are using RSA SecurID Access for SSO, select the Enable the SSO Agent on all identity routers in the cluster checkbox.
If you are using a third-party SSO service or are not using SSO, ensure that the checkbox is cleared.
Note: Enabling the SSO Agent automatically opens the TCP ports 80 and 443 on the identity router. For on-premises identity routers, these ports are opened on the portal interface. If you used the SSO Agent and then clear this checkbox, these ports are disabled along with other ports on the identity router that were enabled when you added applications for SSO.
In the Load Balancer DNS Name field, enter the Load Balancer DNS Name value specified for this cluster in your Quick Setup Guide.
Note: If your deployment uses FIDO authenticators, you must use the same Load Balancer DNS Name for all clusters.
After you finish
You can delete a cluster to remove it from your deployment. Delete clusters using the Cloud Administration Console.
When you delete a cluster, all features and functions provided by that cluster become unavailable. If your deployment requires load balancing between identity routers, session replication, keychain synchronization, or other cluster functionality, you must configure other clusters to provide the necessary capabilities.
Before you begin
The cluster you delete must not be associated with any identity routers. Delete the associated identity routers, or edit them to assign them to other clusters using the Identity Routers page of the Cloud Administration Console.