How does the identity data store, identities and authentication modules interact?
Component 1 - the identity data store
The purpose of the identity data store is to provide information about the authenticated user, which allows you to identify users. This identity data store can be any directory server or an LDAP, and can be new or existing. The identity data store is configured on the Data Store page for each realm; this means you can have completely distinct identity data stores for each realm or inherit the top level realm configuration. It is not always necessary to have an identity data store though as the authentication module can authenticate users without one; this is discussed in Component 4 where other credentials are used for authenticating users and the identity data store is used purely to retrieve the user profile.
In summary, the identity data store allows you to identify your users.
Component 2 - the Identities page (previously the Subjects tab)
The Identities page provides a view of some of your users (first 100 by default). It is a useful way of checking that your connection to the identity data store is working (if you can see your users, you know that you are connected). The Identities page provides basic information about users; you can use this page for simple user management only. You should use a dedicated tool for managing users such as IDM/OpenIDM or DS/OpenDJ, depending on your use case.
In summary, the Identities page allows you check your connection to the identity data store.
Component 3 - authentication modules and how they relate to the identity data store
When configuring user authentication, you create authentication modules and add these modules to chains. A simple way to identify and authenticate a realm user is to use the default DataStore module in a chain. The DataStore module is whatever identity data store you have configured for that particular realm. The resulting flow when using the DataStore module is:
- When the user authenticates, AM/OpenAM validates the credentials entered by the user using the connection details you configured when you created your identity data store.
- Once validated, AM/OpenAM obtains the user details from the directory you use as your identity data store to begin building the user's profile.
This flow explains why the DataStore module configuration is very simple; you configured everything the module needs when you configured the identity data store and added your identities initially.
In summary, the DataStore authentication module uses the identity data store configured for a particular realm.
Component 4 - using something other than the realm identity data store for authentication
To attain flexibility and increase security, we need to provide the capability of authenticating users with a variety of credentials. These credentials may or may not reside in your directory of choice. Further, how users are authenticated depends on a number of things, including the resource you are protecting, its criticality and security requirements, the device they authenticate with, etc. The authentication method / credentials could be Active Directory® (AD) / DS/OpenDJ or other LDAP, SAML, OIDC, RSA token, etc. Therefore, we have decoupled the identity data store (where we identify users, provide the user profile) from the authentication method(s) themselves. This allows us to create and use a variety of other authentication modules, which offers greater flexibility when creating authentication chains, offering different authentication methods, 2FA, etc.
However (and very importantly), any additional authentication methods need to be associated with the identity created in the identity data store via a common attribute so we know who we are dealing with, that is, if a user authenticates against DS/OpenDJ, but your identity data store is AD, we need to be able to identify the authenticated user within the identity data store. To achieve this, we map the identifier of the module to the cn/uid/sAMAccountName/[whatever you use to identify your user in AD] of the identity data store. Without this mapping, we can authenticate users but cannot identity them in the identity data store and therefore cannot retrieve their user profile.
Confusion arises when creating authentication modules. It is possible (and often correct) to re-create a connection to the directory used to populate the identity data store. A common scenario, for example, is you are using a lower level realm to limit the users who can access a resource to a particular geographical location. Provided you use exactly the same unique identifier in your newly created authentication module as you used in your identity data store, it will still work. Therefore, when the user authenticates, AM/OpenAM takes the unique identifier used to authenticate, searches the identity data store with it, finds the appropriate user and is happy. This is a supported approach and entirely appropriate, particularly if you are using numerous modules. However, keep in mind for troubleshooting, if AM/OpenAM cannot find the user using the unique identifier, the authentication will fail.
In summary, you map your authentication module back to a user with a common attribute to allow AM/OpenAM to identify the identity and retrieve the user profile.