PingAM 7.5.1

Identity stores

An identity store, also called an identity repository, is a persistent repository of user data. For example, DS or Microsoft Active Directory. You can configure identity stores either when installing AM, or by adding them to an existing AM instance.

AM also uses other types of data stores, like the configuration data store, the UMA data store, and the Core Token Service (CTS) data store, discussed elsewhere.

When you first set up a realm, the new realm inherits the identity store from the parent realm. For example, in an installation where the Top Level Realm has a DS server as the identity store, any new realm created would have the same DS instance as the identity store, by default.

If your administrators are in one realm and your users in another, your new child realm might retrieve users from a different identity store.

You should not configure more than one writable identity repository in a single realm. AM will try to perform write operations on each identity repository configured in a realm, and there is no way to configure which repository is written to.

To manage identities and reconcile differences between multiple identity repositories, use PingIDM.
Tasks to connect identity stores
Task Resources

Prepare an identity store

You must prepare the identity store before AM can use it.

Prepare identity repositories

Configure an identity store

Configure the store in a realm so that users can be authenticated.

By default, AM re-uses your configuration store as the identity store of the Top Level realm.

Configure an identity store

Customize an identity store

Create custom attributes for your users or custom identity plugins to change how AM maps users and groups to a realm.

Customize identity stores

Configure an identity store

  1. Share the identity store certificate with the AM container to prepare for TLS/LDAPS. Identity stores should communicate over secure connections for security reasons.

    DS 7 or later is configured to require secure connections by default; therefore, share the DS certificate with the AM container before continuing.

    Share the DS certificate with AM

    • On the DS host, export the DS CA certificate.

      DS uses a deployment ID and password to generate a CA key pair. Learn more in Deployment IDs.

      Use the dskeymgr command to export the CA certificate:

      $ /path/to/opendj/bin/dskeymgr \
export-ca-cert \
--deploymentId $DEPLOYMENT_ID \
--deploymentIdPassword password \
--outputFile /path/to/ca-cert.pem

    • Copy the ca-cert.pem file to an accessible location on the AM host.

    • Import the DS certificate into the AM truststore:

      $ keytool \
-importcert \
-file /path/to/ca-cert.pem \
-keystore /path/to/openam/security/keystores/truststore

    Learn more about configuring AM’s truststore in Prepare the truststore.

  2. In the AM admin UI, go to Realms > Realm Name > Identity Stores.

  3. Click Add Identity Store, enter an ID, and select the type of identity store.

  4. Click Create.

  5. In the tabbed view, provide information on how to connect to your identity store.

    Refer to the configuration hints for your identity store:

  6. If you have not applied the schema configuration to your identity data, but the AM service account used to bind to the directory service has permission to alter schema, enable the Load Schema option.

  7. Save your changes.

  8. If you no longer need the connection to the inherited, embedded identity store in this realm, then you can delete its entry in the Identity Stores list.

    Also, once you change the identity store for a realm, you might opt to change the authentication module configuration to use your realm identity store, rather than the inherited settings. Refer to Configure authentication modules.

  9. To test the connection, refer to Test external identity repository access.