Prepare datastores
AM stores different types of information. At a high-level, you can divide information into the following types:
- Configuration
-
Relatively static information that doesn’t change frequently after initial setup. Only administrative users can change it.
- Runtime data
-
Dynamic information that changes at runtime, often due to end user action. Examples of runtime data are identities, CTS tokens, policies, sessions, and applications.
Apart from identity data, AM stores all data after the installation process in its configuration store. This keeps basic deployments simple.
For advanced and high-load deployments, you can configure different sets of replicated DS servers to keep distinct data types separate and to tune DS for different requirements.
AM supports the following datastores:
| Store name | Type of data | Required during installation? |
|---|---|---|
Configuration store (PingDS or FBC) |
Static configuration (properties and settings used by the AM instance). |
Yes |
Identity or user store |
Stores identity profiles; that is, information about the users, devices, or things that authenticate to your systems. You can also configure AM to access existing directory servers to get identity profiles. |
No, but you can configure one during the installation process. |
Policy store |
Stores policy-related data, such as policies, policy sets, and resource types. |
No |
Application store |
Stores application-related data, such as web and Java agent configurations, federation entities and configuration, and OAuth 2.0 client definitions. |
No |
CTS token store |
Stores information about sessions, SAML v2.0 assertions, OAuth 2.0 tokens, and session denylists and allowlists. |
No |
UMA store |
Stores information about UMA resources, labels, audit messages, and pending requests. |
No |
LDAP datastores
The following table lists the supported directory servers for storing different data types:
| Directory server | Versions | Configuration | Apps / policies | CTS | Identities | UMA |
|---|---|---|---|---|---|---|
PingDS |
7.3 and later |
✔ |
✔ |
✔ |
✔ |
✔ |
Oracle Unified Directory |
12c |
✔ |
||||
Microsoft Active Directory |
2019, 2022, 2025 |
✔ |
The procedure for preparing directory servers for AM to use is similar for each data type and includes the following steps:
-
If you don’t have an existing directory server, install the directory server software; for example, PingDS.
-
As the directory administrator, you may need to perform the following steps:
-
Apply the relevant schema to the directory.
-
Create indexes to optimize data retrieval from the directory server.
-
Create a user account with the minimum required privileges for AM to bind to the directory server and access necessary data.
-
To prepare the datastores AM needs during installation, read the following pages:
Where do I find more information about the other datastores?
You can configure all datastores except the configuration store after you install AM:
File-based configuration store
File-based configuration (FBC) is best-suited to a DevOps-style deployment, with the associated tools and practices of that approach.
Static FBC data is written to configuration files in the file system and checked into a source control system, such as Git.
AM instances are created as Docker images, with the FBC incorporated into the image.
You can insert variables into these configuration files before you check them into source control. The variables are substituted with the appropriate values at runtime when you start the Docker container. Using variables lets you reuse the same base configuration files for multiple instances, and different staging environments. For example, development, QA, or pre-production, which are then promoted to production.
Learn more about FBC in Store configuration data in JSON files.
Learn more about installing AM instances with Kubernetes in the ForgeOps documentation.