Cluster Relationships

A cluster relationship synchronizes, or replicates, HTTP Federation (HFED) application sign-in credentials stored in keychain data on the source cluster, with keychain data stored on the target cluster. This enables users with credentials from the source cluster to access the same credentials on the target cluster. After synchronization, users with sign-in credentials in the source cluster have the same credentials in the target cluster.

Note: This information does not apply to the identity router embedded in Authentication Manager.

For more information, see:

Cluster Relationship Overview

To learn about cluster relationships, see:

High Availability with Source and Target Clusters

Cluster relationships enable high availability (HA) between clusters, as described in the following examples.

  • In the event of an unplanned outage on the source cluster, service is restored automatically by switching to the target cluster. Users with identity router sessions on the source cluster are automatically prompted to sign in again, using the same credentials on the target cluster. The location of the cluster storing credentials is transparent to users.
  • With geographically distributed clusters, users traveling between two locations can seamlessly access their HFED applications with the same credentials stored in both cluster locations.
  • In the event of disaster, you can restore service to a source cluster by overwriting keychain data with a backup copy of user keychain data from the target cluster.

Bidirectional Synchronization Between Clusters

Bidirectional synchronization of user keychain data provides service continuity for single sign-on (SSO), as illustrated in the following diagram:
securid_ngx_tg_bidirectional_cluster_relationships.png

In this deployment:

  • Two peer clusters are defined—New York and London.
  • Each cluster has a single identity router.
  • User keychains are replicated in both directions, on both clusters.
  • All users can access the target cluster should the source cluster fail in either direction.

Unidirectional Synchronization Between Clusters

Unidirectional replication of user keychain data can cause unpredictable results in a failure, as shown in the following diagram:
securid_ngx_tg_unidirectional_cluster_relationships.png

In this deployment:

  • Two peer clusters are defined—New York and London.
  • Each cluster has a single identity router.
  • User keychains are replicated in only one direction; New York (source cluster) to London (target cluster).
  • All users can access the London cluster should the New York cluster fail.
  • If the London cluster fails, however, not all users might be able to access their credentials from the New York cluster.

Add a Cluster Relationship

Adding a cluster relationship enables two clusters, a target and a source cluster, to automatically synchronize user keychains. Cluster relationships enable high availability of keychain data among geographically distributed clusters, and facilitate recovery in case of disaster.

Note: This information does not apply to the identity router embedded in Authentication Manager.

Before you begin

  • You must be a Super Admin in the Cloud Administration Console.
  • At least two clusters must exist in your SecurID deployment.
  • Each cluster must contain at least one fully configured identity router.
  • Each cluster must have high availability (HA) enabled.
  • Decide which cluster will be the source cluster, and which will be the target cluster. Consider these factors:
    • During disaster recovery, the target cluster provides recovery data for the source.
    • For HA relationships, clusters can be source and target for each other. For bidirectional HA, a second cluster relationship designates cluster B as the source, and cluster A as the target. For unidirectional HA, one cluster relationship designates cluster A as the source cluster, and cluster B as the target cluster.

Procedure

  1. In the Cloud Administration Console, click Platform > Clusters.
  2. Click Cluster Relationships.
  3. From the Source Cluster drop-down list, select a cluster from which to send keychain data to be synchronized on the target cluster.
  4. From the Target Cluster drop-down list, select the cluster to receive and synchronize the keychain data locally.
    The Port field is read-only and displays the listening port on the target cluster.
  5. In the Timeout field, specify the number of seconds that the source cluster attempts to synchronize with an unresponsive target cluster before failing.
  6. To add another cluster relationship, click ADD and repeat steps 3 through 5.
  7. Click Save.
  8. (Optional) To publish this configuration change and immediately activate it on the identity router, click Publish Changes.

Results

After publishing, keychain synchronization occurs in the background. Each time keychain credentials in the source cluster are changed, a new synchronize operation updates the target cluster.

View Cluster Relationship Status

View the status of cluster relationships in your SecurID deployment.

Procedure

  1. In the Cloud Administration Console, click Platform > Clusters.

  2. Click Cluster Relationships.

  3. Click Get Status to refresh the status for a cluster relationship.
    The Status field displays one of the following values.
    Status Description
    OnlineConnected and operational.
    OfflineNot connected and not operational.
    UnknownNo status information available.
    Pending PublishConfigured and saved but not yet published.

Delete a Cluster Relationship

Deleting a cluster relationship disables keychain synchronization between the designated target and source clusters. Deleting a cluster also deletes any cluster relationship that includes the deleted cluster.

Before you begin

You must be a Super Admin in the Cloud Administration Console.

Procedure

  1. In the Cloud Administration Console, click Platform > Clusters.

  2. Click Cluster Relationships.

  3. To the far right of the cluster relationship you want to delete, click the minus symbol (-).

  4. Click Save.
    If you click Cancel, or navigate away from the Cluster Relationships page without clicking Save, the delete operation is ignored.
  5. (Optional) To publish this configuration change and immediately activate it on the identity router, click Publish Changes.