The term user store can be used to refer to one of the following data stores in AM:
- Authentication - this data store contains the credentials used for authenticating a user. The location of this data store is determined by the type of Authentication module you are using and how it has been configured. For example, if you are using the LDAP authentication module, the user's credentials will be stored on your LDAP server. This data store is also referred to as the Credential Store.
- User profiles - this data store contains user profiles or identity data (attributes) for users who have authenticated to AM. The location of this data store is determined by the data store you have configured for the applicable realm. This data store is also referred to as the Identity Data Store or Identity Repository. You can check what data store has been configured in a realm by navigating to Realms > [Realm Name] > Data Stores. in the console.
When a user wants to access an application protected by AM, they supply credentials (such as user name and password) to log in. These credentials are then validated against the ones held in the Credential store (authentication); if they match, the user successfully authenticates to AM and the user profile is retrieved if an Identity data store is configured.
Although these two user stores are conceptually different, they may in fact refer to the same data store. For example, if you are using the LDAP authentication module and have also configured your LDAP server to be used as the data store, then these user stores will be the same.
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. 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 only. You should use a dedicated tool for managing users such as IDM or DS, 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 validates the credentials entered by the user using the connection details you configured when you created your identity data store.
- Once validated, AM 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 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, 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 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 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 to identify the identity and retrieve the user profile.