Configure secret stores after upgrade
Secret stores are repositories of cryptographic keys, key pairs, and credentials.
|
Follow these steps to make the secret stores available to other servers in the site:
Redeploy secret stores to a site after upgrade
You can reconfigure the secret stores and their mappings after upgrade. However, we recommend that you follow the steps in this procedure to ensure all secrets are available to all the instances in the site, and later on, you make additional changes to your environment.
The upgrade process creates several secret stores, globally and by realm, depending on the features configured in AM:
-
Go to Configuration > Secret Stores, and review the global secret stores created for your environment.
-
Make sure the keystores configured exist on the other servers within the site. You might need to copy the keystores across or make them available in some other way.
-
Make sure directories configured in file system secret stores and their content exist on the other servers within the site. You might need to copy the directories across or make them available in some other way.
-
-
Go to Realms > Realm Name > Secret Stores, and perform the same actions you took for the global secret stores.
Realm-based secret stores are created for those features that support different keystore configurations by realm. For example, SAML v2.0, or the persistent cookie decision node.
To find the realm-based secret stores, go to Realms > Realm Name > Secret Stores. The secrets themselves are stored in the
/path/to/am/security/secrets/realms/root/realm-name/secret-store-name
directory.Repeat this step for each of the realms you have configured.
-
Deploy the new AM
.war
file on the rest of the AM servers. -
When the site is up, and before opening the service to end users, review the secret label mappings of the new secret stores and change them as required.
For example, the upgrade process could have created secret stores for features you aren’t using. These secret stores could have mappings to secrets that don’t exist. It’s advisable to remove unused secret mappings in production environments.
Learn more about available secret labels in Secret label default mappings.
Reference: SAML v2.0 mappings after upgrade
AM is flexible regarding the configuration of secrets for SAML v2.0. Therefore, migrating the different combinations may create a high number of secret labels in your environment.
As a rule of thumb, AM configures providers that were using the same key aliases in the same order, to use the same secret labels. If this rule can’t be satisfied, the upgrade process creates new secret labels for the provider by assigning it a secret label identifier.