Types of Configuration
This documentation describes the legacy CDK implementation, which will be deprecated in an upcoming release. We strongly recommend that you transition to the current CDK implementation as soon as possible.
Static configuration consists of properties and settings used by the ForgeRock Identity Platform. Examples of static configuration include AM realms, AM authentication trees, IDM social identity provider definitions, and IDM data mapping models for reconciliation.
Static configuration is stored in JSON configuration files. Because of this, static configuration is also referred to as file-based configuration.
You build static configuration into the
idm Docker images during development, using the
following general process:
Change the AM or IDM configuration in the CDK using the UIs and APIs.
Export the changes to your
Build a new AM or IDM Docker image that contains the updated configuration.
Restart ForgeRock Identity Platform services using the new Docker images.
Test your changes. Incorrect changes to static configuration might cause the platform to become inoperable.
Promote your changes to your test and production environments as desired.
See AM and IDM Images for more detailed steps.
In ForgeRock Identity Platform deployments, static configuration is immutable. Do not change static configuration in testing or production. Instead, if you need to change static configuration, return to the development phase, make your changes, and build new custom Docker images that include the changes. Then, promote the new images to your test and production environments.
Dynamic configuration consists of access policies, applications, and data objects used by the ForgeRock Identity Platform. Examples of dynamic configuration include AM access policies, AM OAuth 2.0 client definitions, and IDM relationships.
In ForgeRock Identity Platform deployments, dynamic configuration is not immutable. You can change dynamic configuration at any time, including when the platform is running in production.
You’ll need to devise a strategy for managing AM and IDM dynamic configuration, so that you can:
Extract sample dynamic configuration for use by developers.
Back up and restore dynamic configuration.
The CDK and CDM run an Amster job when they start. The job loads dynamic configuration required by the CDK and CDM into the AM application and policy store.
The required dynamic configuration is stored in the
See xref:legacy/cdk/develop/am-idm.adoc for detailed steps to build the
Identities are another type of dynamic configuration. They can be modified at any time, including when the platform is running in production. Identities are never incorporated into Docker images for the platform.
As with AM and IDM dynamic configuration, you’ll need to devise a strategy to manage identities that lets you:
Extract sample user identities that can be used by developers.
Back up and restore user identities.
A ForgeRock Identity Platform configuration profile is a named set of configuration that describes the operational characteristics of a running ForgeRock deployment. A configuration profile consists of:
AM static configuration.
IDM static configuration.
AM dynamic configuration to be loaded into the AM application and policy store when the CDK and CDM start up.
Configuration profiles reside in two locations in the
The master directory. Holds a canonical configuration profile for the CDK and user-customized configuration profiles. User-customized configuration profiles in this directory are considered to be the source of truth for ForgeRock Identity Platform deployments.
The master directory for configuration profiles is located at the path /path/to/forgeops/config/7.0. Use Git to manage the configuration profiles in this directory.
The staging area. Holds a single configuration profile. You copy a profile from the master directory to the staging area before building a customized Docker image for the ForgeRock Identity Platform.
The staging area is located in subdirectories of the path, /path/to/forgeops/docker/7.0. Configuration profiles copied to the staging area are transient and are not managed with Git.
The config.sh script lets you copy configuration profiles between the master directory and the staging area. You run this script before you build customized Docker images for the platform. The script lets you specify which configuration profile to copy to the staging area. The skaffold run command uses the profile that’s been copied to the staging area when it builds a Docker image.