This section contains the following topics:
Policy Server Encryption Keys Overview
Reset the r6.x Policy Store Encryption Key
Reset the r12.x Policy Store Encryption Key
Configure Agent Key Generation
Shared Secret for a Trusted Host
The Policy Server and Agents use encryption keys to encrypt and decrypt sensitive data passed between Policy Servers and Agents in a SiteMinder environment.
Both types of keys are kept in the Policy Server's key store and distributed to Agents at runtime. By default, the key store is part of the Policy Store, but a separate key store database can be created if desired.
Other, special keys are:
To keep key information updated across large deployments, the Policy Server provides an automated key rollover mechanism. You can update keys automatically for Policy Server installations that share the same key store. Automating key changes helps ensure the integrity of the keys.
For CA SiteMinder® agents that are configured for single sign–on:
If the Policy Server determines that a stand–alone key store is unavailable, it attempts to reconnect to the key store to determine availability. If the connection fails, the Policy Server:
A Policy Server in a suspended state remains up for the length of time specified in SuspendTimeout. The Policy Server then shuts down gracefully. If SuspendTimeout is equal to zero, the Policy Server remains in the suspended state until the key store connection is reestablished.
Additionally, when the Policy Server is started and the key store is unavailable, the Policy Server shuts down gracefully.
Use the Administrative UI to manage keys.
The Federal Information Processing Standards (FIPS) 140-2 publication specifies the requirements for using cryptographic algorithms within a security system protecting sensitive, unclassified data. SiteMinder embeds RSA 's Crypto-C ME v2.0 cryptographic library, which has been validated as meeting the FIPS 140-2 Security Requirements for Cryptographic Modules. The validation certificate number for this module is 608.
SiteMinder's Java-based APIs use a FIPS-compliant version of the Crypto-J cryptographic library.
SiteMinder can operate in a pre-FIPS mode or in a FIPS-only mode. The cryptographic boundaries, that is, the way SiteMinder applies encryption, are the same in both modes, but the algorithms are different.
In FIPS-only mode, SiteMinder uses the following algorithms:
The SiteMinder core components make extensive use of encrypted data:
The Policy Store Key is used to encrypt sensitive data stored in the Policy Store. It is derived from a seed string entered during the installation of the Policy Store. The Policy Store Key is also encrypted, using the Host Key, and stored in a system-local file. To support unattended operation, the Host Key is a fixed key embedded in the Policy Store code. Agents use this same Host Key mechanism to encrypt and store their copies of their Shared Secrets.
The Session Ticket Key (used by the Policy Server to form authentication tokens) and Agent Keys (primarily used by Web Agents to encrypt cookie data) are encryption keys stored in the Policy Store (or Key Store, depending on SiteMinder configuration settings) in encrypted form. They are encrypted using the Policy/Key Store Key. The Key Store Key is encrypted in the Policy Store. Agent Shared Secrets (used for Agent authentication and in the TLI Handshake), along with other sensitive data, are also encrypted with the Policy Store Key and stored in the Policy Store.
SiteMinder Web Agents use an Agent key to encrypt cookies before passing the cookies to a user’s browser. When a Web Agent receives a SiteMinder cookie, the Agent key enables the Agent to decrypt the contents of the cookie. Keys must be set to the same value for all Web Agents communicating with a Policy Server.
The Policy Server provides the following types of Agent keys:
Note: A static agent key is always generated at installation. This static key is used for certain other product features, such as user management, whether or not you use the static key as the Agent key.
Dynamic Agent key rollover is configured in the Key Management dialog of the FSS Administrative UI. Web Agents poll the Policy Server for key updates at a regular interval. If keys have been updated, Web Agents pick up the changes during polling. The default polling time is 30 seconds, but can be configured by changing the pspollinterval parameter of a Web Agent.
Note: For information about changing the parameters of a Web Agent, see the CA SiteMinder® Web Agent Configuration Guide.
The Policy Server uses an algorithm to generate dynamic keys at a regular interval. These keys are saved in the key store. When a Web Agent detects new keys, it retrieves them from the key store.
You configure dynamic agent key rollover in the Administrative UI. Web agents poll the Policy Server for key updates at a regular interval. If keys have been updated, web agents pick up the changes during polling. The default polling time is 30 seconds, but you can change the default by changing the pspollinterval parameter of a web agent.
Note: For information about changing the parameters of a web agent, see the CA SiteMinder® Web Agent Configuration Guide.
The Policy Server uses an algorithm to generate dynamic keys at a regular interval. These keys are saved in the key store. When a web agent detects new keys, it retrieves them from the key store.
CA SiteMinder® deployments use the following keys in a dynamic key rollover and maintain them in the key store:
When the Policy Server processes a dynamic Agent key rollover, the value of the current key replaces the value of the old key. The value of the future key replaces the value of the current key, and the Policy Server generates a new value for the future key.
When receiving a cookie from a client browser, the Web Agent uses the current key from the key store to decrypt the cookie. If the decrypted value is not valid, the Web Agent tries the old key, and if necessary, the future key. The old key may be required to decrypt cookies from an Agent that has not yet been updated, or to decrypt existing cookies from a client’s browser. The future key may be required for cookies created by an updated Agent, but read by an Agent that has not yet polled the key store for updated keys.
At a specified time, the Agent key rollover process begins. To prevent multiple rollovers from multiple Policy Servers, each server sets a rollover wait time of up to 30 minutes. If no update has been performed by the end of the wait time, that Policy Server updates the keys.
All Policy Servers wait for updated keys and then process the new keys to their Agents. Even for a single Policy Server, the update time may be up to 30 minutes beyond the time specified for the rollover.
The Agent Key Rollover process begins at the time(s) specified in the CA SiteMinder® Agent Key Management dialog box. The process can take up to three minutes. In that time period, all Web Agents connected to the Policy Server receive updated keys.
Note: In a deployment that involves multiple replicated Policy Servers, the process for distributing Agent keys may take up to 30 minutes.
A static key is a string used to encrypt data which remains constant. In a SiteMinder deployment that uses the Agent Key rollover feature, a static key provides a method for maintaining user information across an extended period of time.
The following SiteMinder features and situations make use of the static key:
If an HTML Forms authentication scheme has been configured to allow users to save credentials, the Policy Server uses the static key to encrypt the user’s credentials.
If user tracking is turned on, the Policy Server uses the static key to encrypt user identity information.
In a SiteMinder deployment that includes multiple key stores, the static key may be used for single sign-on. In this situation, SiteMinder Agents use the static key for all cookie encryption.
Note: If you change the static key, any cookies created with the former static key are invalid. Users may be forced to re-authenticate, and user tracking information becomes invalid. In addition, if the static key is used for single sign-on, users are challenged for credentials when they attempt to access resources in another cookie domain.
When a user successfully logs into a protected resource, the Policy Server creates a session ticket. The session ticket is what the Policy Server uses to determine how long a user’s authentication remains valid. This session ticket is encrypted using the session ticket key and cached in the Agent User Cache.
You can choose to have the Policy Server generate the session ticket key using an algorithm, or you can enter a session ticket key in the CA SiteMinder® Key Management dialog box. For security reasons, the randomly generated key is recommended.
However, if your CA SiteMinder® implementation includes multiple key stores in a single sign-on environment, you must use the same session ticket key for all key stores.
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:
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.
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.
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.
When deciding on the key management scenario for your enterprise, consider the following:
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.
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.
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:
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.
To reset the r6.x policy store encryption key
smobjexport -dsiteminder_administrator -wpassword -ofile_name -c
Specifies the name of the CA SiteMinder® administrator account.
Note: This administrator must be able to manage all CA SiteMinder® domain objects.
Specifies the password of the CA SiteMinder® administrator account.
Specifies the following:
Note: If this argument is not specified, the default output file names are stdout.smdif and stdout.cfg.
Exports sensitive data as clear–text.
The utility exports the policy store data into the smdif file.
Specifies the Policy Server installation path.
Note: If the utility is not present, you can find the utility in the Policy Server installation media, which is available on the Support site.
smreg -key encryption_key
Specifies the new encryption key.
Limits: 6 to 24 characters.
The policy store encryption key is changed.
The administrator password is re–encrypted using the new encryption key.
smreg -su password
Specifies the CA SiteMinder® super user password.
The super user password is set and encrypted using the new encryption key.
smobjimport -dsiteminder_administrator -wpassword -ifile_name -r -f -c
Specifies the name of the CA SiteMinder® administrator account.
Note: This administrator must be able to manage all CA SiteMinder® domain objects.
Specifies the password of the CA SiteMinder® administrator account.
Specifies the following:
Note: If this argument is not specified, the default input file names are stdout.smdif and stdout.cfg.
Specifies that duplicate policy store information can be overwritten during the import.
Turns off automatic renaming of objects. By default, when the utility attempts to import an object with a name that exists in the target policy store, the utility creates a duplicate object. The name of the object is nameoid.
name
Specifies the name of the object.
oid
Specifies the object ID of the new duplicate object.
The utility returns errors messages for any objects that could not be created because of naming conflicts.
Indicates that the input file contains sensitive data in clear–text.
smreg -su password
Specifies the CA SiteMinder® super user password.
The super user password is set.
The policy store encryption key is reset.
Follow these steps:
Note: Stop all Policy Servers pointing to the policy store before changing the encryption key.
xpsexport <filename> -xb –npass
or (for encrypted output)
xpsexport <filename> -xb –pass <password>
smkeyexport –o <filename> -d<sm admin name> -w<smadmin password> -c
smreg –key <new key>
Use the "Data" tab of SmConsole to re-enter the previously configured password, apply the change and then use the "Test Connection" button to verify.
xpsimport <filename> –fo –pass <password>
or (if no password was used to create the export file):
xpsimport <filename> –fo –npass
smkeyimport –i<filename> -d<sm admin name> -w<sm admin password> -c
The policy store encryption key is reset.
You use the Policy Server Management Console Keys tab to configure how the Policy Sever handles Agent key generation.
Note: Enable key generation only on the Policy Server that you want to generate Agent keys.
To configure Policy Server agent key generation
Important! If you are accessing this graphical user interface on Windows Server 2008, open the shortcut with Administrator permissions. Use Administrator permissions even if you are logged in to the system as an Administrator. For more information, see the release notes for your CA SiteMinder® component.
Note: For more information about the settings and controls on this tab, click Help, Management Console Help.
The SiteMinder Key Management dialog box, which you access from the Administrative UI, enables you to configure periodic Agent key rollovers, execute manual rollovers, and change the static key. It also enables you to manage the session ticket key.
Note: To manage keys, you must log into the Administrative UI using an account with the Manage Keys and Password Policies privilege. For more information, see the Policy Server Configuration Guide.
The Policy Server supports periodic Agent key rollovers at the following frequencies:
The shortest allowable period between rollovers is one hour.
Note: Be sure that your operating system is configured to adjust the system time for daylight savings time. A system that is not configured for daylight savings time can offset key rollover by one hour.
Follow these steps:
Important! After selecting Use dynamic Agent key, you cannot click Rollover Now until you save the periodic key rollover configuration settings.
Agent key rollover is configured.
You can roll over dynamic agent keys manually. This feature:
Follow these steps:
The Policy Server generates new agent keys immediately. Unless you manually execute an agent key rollover, the Policy Server does not generate new dynamic keys automatically.
Note: Do not click this button multiple times, unless you want to roll over keys more than once.
Web agents pick up the new keys the next time they poll the Policy Server. This action can take up to 3 minutes due to cache synchronization. If you want to use an entirely new set of keys for security reasons, roll over dynamic keys twice. This action removes the old key and the current key from the key store.
You must coordinate the updating of agent keys and session timeouts or you may invalidate cookies that contain session information. This coordination is critical because the person designing policies in your organization may be different than the person configuring dynamic key rollover.
Session timeouts should be less than or equal to two times the interval configured between Agent key rollovers. If an administrator configures an agent key rollover to occur two times before a session expires, cookies written by the Web Agent before the first key rollover will no longer be valid and users will be re-challenged for their identification before their session terminates.
For example, if you configure key rollover to occur every three hours, you should to set the Maximum Session timeout to six hours or less to ensure that multiple key rollovers do not invalidate the session cookie.
You can change the static gent key web agents use to encrypt identity information for certain features.
Important! We do not recommend changing the static key. Change the static key only in extreme situations, such as security breaches. This action can cause some CA SiteMinder® features to lose the data they require to function properly. Features that establish and use an identity stored in a persistent cookie will no longer work. Authenticated users can be forced to log in again before single sign–on functions across multiple CA SiteMinder® installations.
A static key can also be used to maintain a single sign–on environment that requires multiple Policy Servers and multiple master key stores.
Follow these steps:
The Policy Server generates a new random static key.
Use this option in situations where two key stores must use the static key to maintain a single sign–on.
The static key rolls over within 3 minutes.
The Policy Server can generate the session ticket key using an algorithm, or you can enter the session ticket key manually. A session ticket is established each time a user authenticates successfully and enables the Policy Server to determine how long a user’s session can continue.
Note: The only implementation that requires a manually assigned session ticket key is one that includes multiple, independent key stores. Automatically generated keys cannot be propagated across independent key stores by the Policy Server. In all other instances it is recommended that you use the session ticket key generated by the Policy Server algorithm.
The Policy Server can generate the session ticket key using a method similar to the one for generating dynamic agent keys. Randomly generating the session ticket key lets the Policy Server use an algorithm to create the key used for encryption and decryption.
Follow these steps:
The Policy Server generates a new session ticket key. This key immediately replaces the one that is used to encrypt and decrypt session tickets.
The Policy Server immediately replaces the existing session ticket key with the value you entered.
If your Policy Server is part of an implementation that includes multiple key stores, you can manually enter the session ticket key.
Follow these steps:
The Policy Server immediately replaces the existing session ticket key with the value you entered.
When a single Policy Server generates encryption keys in an environment with multiple Policy Servers that connect to disparate policy stores, but share a central key store, an additional registry setting is required. This registry setting configures each Policy Server to poll the common key store and retrieve new encryption keys at a regular interval.
To configure the EnableKeyUpdate registry key on a Windows Policy Server
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\ CurrentVersion\ObjectStore
"EnableKeyUpdate"=0
to
"EnableKeyUpdate"=1
To configure the EnableKeyUpdate registry key on a UNIX Policy Server
install_directory/siteminder/registry
HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\SiteMinder\ CurrentVersion\ObjectStore
"EnableKeyUpdate"=0
to
"EnableKeyUpdate"=1
When you register a trusted host, the installation process:
If you enabled shared secret rollover when registering a trusted host, you can roll over the shared secrets for trusted hosts either manually or periodically.
During a manual or periodic shared secret rollover, shared secrets are only rolled over for agents that were configured at installation to allow rollovers.
Note: For more information about installing web agents and registering trusted hosts, see the CA SiteMinder® Web Agent Installation Guide.
Shared secret rollover occurs automatically only on servers that are configured to enable agent key generation. You enable agent key generation by selecting the Enable Agent Key Generation check box in the Keys tab of the Policy Server Management Console. This setting is enabled by default.
Important! We recommend that you only enable one Policy Server to generate keys. If there are multiple policy stores in an environment, but only a single shared key store, not all shared secrets roll over automatically. The shared secrets are only rolled over automatically if the Policy Server to which the policy store is configured is enabled for key generation. All other policy stores require that you execute a rollover manually.
Use one of the following to roll over the shared secret manually:
Note: The shared secret policy object is kept in the key store. All policy stores that share the same key store share the same secret. The shared secrets themselves are kept in the trusted host objects, which are part of the policy store.
The Policy Server supports manual and periodic rollover of shared secrets for trusted hosts.
Periodic rollovers can be configured hourly, daily, weekly, or monthly; one hour is the shortest allowable period between rollovers. The Policy Server initiates periodic rollovers based on the age of the shared secret for each trusted host, rather than at a specific time of the day, week, or month. By rolling over each shared secret as it expires, the processing associated with the rollover is distributed over time, and avoids placing a heavy processing load on the Policy Server.
If you use the manual rollover feature, future periodic rollovers will generally be clustered together for all trusted hosts, since the manual rollover sets new shared secrets for all trusted hosts that allow shared secret rollover.
Important! If you enable key generation on more than one Policy Server associated with a single policy store, the same shared secret can be rolled over more than once in a short period of time due to object store propagation delays. This can result in orphaned hosts whose new shared secrets have been discarded. To avoid this potential problem, enable shared secret rollover for a single Policy Server per policy store.
Follow these steps:
Rollover Frequency
Enter an integer for the number of times a rollover should occur. This number works together with the value of the rollover period.
Rollover Period
From the pull-down list, select Hours, Days, Weeks or Months for the occurrence of the rollover.
The Policy Server begins the process of rolling over shared secrets for all trusted hosts configured to allow shared secret rollover. The rollover may take some time depending on the number of trusted hosts in your deployment.
|
Copyright © 2013 CA.
All rights reserved.
|
|