Configure CTS token stores
The following table summarizes the high-level tasks you must perform to configure a new instance of the CTS token store:
Prepare a DS Server
Prepare the DS schema for CTS data.
Configure AM to Use the New CTS Token Store
Configuring a new CTS data store does not migrate existing data from the old store to the new one. In most cases, this will mean that users will need to log in again so that AM stores their sessions and tokens in the new token store.
Test Session High-Availability
For this test, you need to have a site with more than one instance. The idea is to log in a user into the first instance, shut it down, and check that the session is still available to the second instance.
Directory Services 6.5 added support for setup profiles to simplify initial configuration. Using a setup profile creates the backend, schema, bind user, and indexes required for use with CTS data.
To install DS using a setup profile, follow the steps in Install DS for AM CTS in the Directory Services documentation.
Share the CTS store certificate with the AM container to prepare for TLS/LDAPS. The CTS store should communicate over secure connections for security reasons.
DS 7 and later requires secure connections by default; therefore, share its certificate with the AM container before continuing.
Share the DS certificate with AM
Export the DS server certificate:
$ keytool -exportcert \ -keystore /path/to/opendj/config/keystore \ -storepass $(cat /path/to/opendj/config/keystore.pin) \ -alias ssl-key-pair \ -rfc \ -file ds-cert.pem
The default DS server certificate only has the hostname you supplied at setup time, and
localhost, as the value of the
SubjectAlternativeNameattribute; however, certificate hostname validation is strict. Ensure that the certificate matches the hostname (or the FQDN) of the DS server before continuing.
ds-cert.pemfile to an accessible location on the AM host.
Import the DS certificate into the AM truststore:
$ keytool \ -importcert \ -file ds-cert.pem \ -keystore /path/to/openam/security/keystores/truststore
For more information on configuring AM’s truststore, see Prepare the truststore.
Proceed to configuring the CTS store in AM. See Configure the CTS.
The bind DN of the service account to use when configuring the CTS store in AM is
This procedure assumes that the AM instances communicate with a single CTS instance (or load balancer),
which has an FQDN of
cts.example.com and is running on port
If AM cannot access the CTS token store, you will be unable to log in to the AM admin UI.
Back up your deployment before making any changes to your CTS token store configuration.
Perform the following steps to configure an external CTS token store:
In the AM admin UI, go to Configure > Server Defaults, and click CTS.
On the CTS Token Store tab, configure the parameters as follows:
CTS Token Store Parameters Parameter Value Notes
External Token Store
For production, this value needs to be tuned. Consider 2n+1, where n=4, 5, 6, and so on. For example, try setting this to 17, 33, 65, and test performance under load.
On the External Store Configuration tab, configure the parameters as follows:
External Store Configuration Parameters Parameter Value Notes
When connecting to DS 7, or a DS server in production mode, enable secure connections. When you enable SSL/TLS, make sure the AM server can trust the DS server certificate and that the certificate matches the CTS store FQDN.
Use the LDAPS port. Alternatively, use the LDAP port with StartTLS, as in
The bind DN of the service account AM uses to connect to the directory service.
Use a strong bind password for production systems.
For production, this value needs to be tuned.
Save your work.
Restart AM or the web container where it runs for the changes to take effect.
To test session availability, use two browsers: Chrome and Firefox. You can use any two browser types, or run the browsers in incognito mode. You can also view tokens using an LDAP browser.
In Chrome, log in to the second AM instance with the
amAdminuser, click the realm, and click Sessions.
In Firefox, log in to the first AM instance with a test user.
In Chrome, verify that the test user exists in the first AM instance’s session list and not in the second instance.
Shut down the first AM instance.
In Firefox, rewrite the URL to point to the second AM instance.
If successful, the browser should not prompt for login.
Confirm the session is still available.
In Chrome, list the sessions on the second instance, the test user’s session should be present.
Restart the first AM instance to complete the testing.