Cluster Relationships

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

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.

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:

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:

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.

 

 

Previous Topic:Add a Cluster
You are here
Table of Contents > Clusters and Backups > Cluster Relationships

Attachments

    Outcomes