Policy Server Guides › Policy Server Administration Guide › Configuring and Managing Encryption Keys › Key Management Scenarios

Key Management Scenarios

There are three types of scenarios for key management based on how you implement Policy Servers, policy stores and key stores, along with your single sign-on requirements. These scenarios include:

• Common Policy Store and Key Store

  In this scenario, a group of Policy Servers shares a single policy store and key store, providing access control and single sign-on in a single cookie domain.

  The policy store data is maintained in a single policy store. Key data is maintained in a single key store. The key store may be part of the policy store, or may be a separate store.

  Both policy store and key store data may be replicated for failover purposes. Replication must be configured based on the database or directory type selected for the policy store. For information about replication schemes, consult the documentation provided by your database or directory vendor.

• Multiple Policy Stores with a Common Key Store

  In this scenario, groups of Policy Servers connect to separate policy stores, but share a common key store, providing access control and single sign-on across multiple cookie domains.

  The policy store data for each group of Policy Servers is maintained in a single policy store. Key data for all groups of Policy Servers is maintained in a single key store. The separate key store allows Agents associated with all Policy Servers to share keys, enabling single sign-on across separate cookie domains.

  Both policy store and key store data may be replicated for failover purposes. Replication must be configured based on the database or directory type selected for the policy store. For information about replication schemes, consult the documentation provided by your database or directory vendor.

• Multiple Policy Stores and Multiple Key Stores

  In this scenario, each group of Policy Servers shares a single policy store and key store, providing access control and single sign-on across multiple cookie domains where it is desirable for the Policy Servers in each cookie domain to have a separate key store.

  The policy store data for each group of Policy Servers is maintained in a single policy store. Key data for each group of Policy Servers is maintained in a single key store. The key store may be part of the policy store, or may be a separate store. The same set of static keys allows for single sign-on across all Web Agents.

  Both policy store and key store data may be replicated for failover purposes. Replication must be configured based on the database or directory type selected for the policy store. For information about replication schemes, consult the documentation provided by your database or directory vendor.

More information:

Configure LDAP Failover

Configure ODBC Failover

Key Management Considerations

When deciding on the key management scenario for your enterprise, consider the following:

• When configuring dynamic keys in an environment with multiple Policy Servers that share a common key store, a single Policy Server must be nominated to perform Agent Key generation. You should disable key generation on all other Policy Servers.
• In a network configuration with multiple Policy Servers, the Policy Server Management Console enables you to specify a policy store for each Policy Server. Policy stores can be master policy stores that are the primary location for storing CA SiteMinder® objects and policy information, or they can be replicated policy stores that use data copied from a master policy store.
• Master/slave directories or databases must be configured according to the specifications of the directory or database provider. The Policy Server provides the ability to specify a failover order for policy stores, but it does not control data replication. For information about replication schemes, see your directory or database provider’s documentation.
• In any network that uses dynamic key rollover, the key store for a Policy Server may be a master key store or a replicated slave key store. Master key stores receive keys directly from the Policy Server process that generates the keys. Slave key stores receive copies of the keys in the master key store.
• In a master/slave environment, you must configure key generation from Policy Servers that point to the master policy store and key store. The master policy store and key store data must then be replicated across all other policy stores and key stores included in your failover order.
• In any single sign-on environment for multiple cookie domains, dynamic keys can only be used if there is a single master key store, or slave key stores with keys replicated from a single master key store.
• Policy stores and keys stores can be installed on mixed LDAP and ODBC directories. The policy store can reside in an ODBC database and the key store can reside in an LDAP Directory Server or vice versa. For a list of supported databases, go to the Technical Support site and search for the CA SiteMinder® 12.51 Platform Support Matrix.

More information:

Configure LDAP Failover

Configure ODBC Failover

Common Policy Store and Key Store

The simplest scenario for a SiteMinder configuration that uses key rollover is when multiple Policy Servers use a single policy store (and its associated failover policy stores), along with a single key store.

The following figure shows multiple Policy Servers using a single policy store.

In this type of configuration, Policy Servers retrieve dynamic keys from the key store. The Web Agents associated with the Policy Servers collect new keys from the Policy Servers.

More information:

Key Management Considerations

Multiple Policy Stores with a Common Key Store

If a network configuration consists of multiple Policy Servers with separate policy stores in a single sign-on environment, it is possible to have a common key store that all of the Policy Servers use for key rollover.

The following figure shows multiple Policy Servers using a common key store.

One Policy Server generates dynamic keys and stores them in the central key store. Each Policy Server is configured using the Policy Server Management Console to use the central key store; Agent key generation should be disabled for all other Policy Servers. Agents poll their respective Policy Servers to retrieve new keys. The Policy Servers retrieve new keys from the common key store and pass them to the CA SiteMinder® Agents.

Note: This scenario requires an additional registry setting that forces Policy Servers that are not generating keys to poll the key store for key updates.

More information:

Key Management Considerations

Set the EnableKeyUpdate Registry Key

Multiple Policy Stores with Separate Key Stores

If a network configuration is composed of multiple Policy Servers, policy stores, and master key stores, an administrator with appropriate privileges can specify the same static key and session ticket key for each policy store in order to facilitate one or more of the following:

• Single sign-on across all Agents
• Password Services with a common user directory

The following figure shows an environment with multiple Policy Servers and stores.

In the previous example, the same static key is used to encrypt all cookies created by CA SiteMinder® Web Agents.

More information:

Key Management Considerations