Access Management 7.4.1

Deployment configuration locations

Every AM deployment has associated configuration data. Configuration data consists of properties and settings used by the AM instance to function.

Configuration data is often referred to as static, because after your instance is configured to your requirements, it does not need to be changed.

Configuration data includes properties and settings for the following:

  • Global services

  • Realms

  • Authentication trees

Configuration data can be stored in the following places, each tailored to particular deployment requirements:

Embedded DS instance

For evaluation deployments, you can store all your configuration data in the single, embedded DS server that is included in AM.

Standalone, evaluation deployments can use the embedded DS.
Use of embedded DS servers for production deployments is not supported as of AM 7.

For information on installing an AM instance for evaluation, see Evaluation.

External DS instances

Storing configuration data in external DS data stores offers deployment flexibility and provides instance high availability.

Configuration data in the DS instances is shared between the AM instances in your deployment. The configuration data can be replicated between multiple DS instances in a cluster, and made available to AM instances in different regions, improving availability, and data integrity.

Replicate data between multiple DS instances in a cluster.

For information on installing AM instances with external data stores, see Installation.

Files

File-based configuration is used specifically for automated cloud deployments, and only available and supported when used within Docker images.

AM’s static configuration data is written to files in the file system, and checked into a source control system, such as Git.

AM instances are created as Docker images, with the file-based configuration incorporated in the image.

Kubernetes deployments can use file-based configuration.

You can insert variables into these configuration files before checking them into source control. These variables are substituted with the appropriate values at runtime, when starting up an image, so that the same base configuration files can be reused for multiple instances, and different staging; for example, development, QA, or pre-production, then promoted to production.

For information on installing AM instances with Kubernetes, see the ForgeRock DevOps (ForgeOps) documentation.

AM instances also create dynamic, run-time data. This data can change and grow often, even in a production instance, as business logic changes.

Dynamic data includes properties, settings, and values for the following:

  • Policies, policy sets, and resource types

  • OAuth 2.0 client profiles

  • Federation entities

  • Core Token Service (CTS) tokens

  • UMA resources, labels, audit messages, and pending requests

Dynamic data is stored in one or more DS instances. You can choose to store dynamic data alongside the configuration data, or separate it into different data stores.

How you separate dynamic data into data stores will depend on the amount dynamic data you expect to handle. For example, CTS data is often highly volatile and short lived, so it warrants its own set of tuned DS instances. The other dynamic data types may not be so volatile, and could potentially all share a set of differently tuned DS instances.

For information on setting up external stores for use with AM, see Prepare external stores