About Data Used by the Platform

The ForgeRock Identity Platform uses two types of data: configuration data and run-time data.

Configuration Data

Configuration data consists of properties and settings used by the ForgeRock Identity Platform. You update configuration data during the development phase of ForgeRock Identity Platform implementation. You should not change configuration data during the testing and production phases.

You change configuration data iteratively in a development environment. After changing configuration data, you rebuild Docker images and restart ForgeRock Identity Platform services when you’re ready to test sets of changes. If you make incorrect changes to configuration data, the platform might become inoperable. After testing modifications to configuration data, you promote your changes to test and production environments.

Examples of configuration data include AM realms, AM authentication trees, IDM social identity provider definitions, and IDM data mapping models for reconciliation.

Configuration Profiles

A ForgeRock Identity Platform configuration profile is a named set of configuration data that describes the operational characteristics of a running ForgeRock deployment.

Configuration profiles reside in two locations in the forgeops repository:

  • 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. You 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. It also lets you copy profiles from Kubernetes pods running ForgeRock Identity Platform components to the staging area.

You run this script before you build a customized Docker image for the platform. The script lets you specify which configuration profile to copy to the staging area. Skaffold uses this profile when it builds a Docker image.

For example, when you start developing customized images for the platform, you run the config.sh init command to initialize the staging area with the canonical CDK profile:

This diagram shows how the staging area is initialized from the canonical ${cdk.abbr} profile.

You run the config.sh sync command to synchronize configuration changes you’ve made in a running deployment back to the staging area, and then to the master directory:

This diagram shows how the config.sh command synchronizes a configuration profile.

For more information about the config.sh script, see Managing Configurations in the forgeops repository’s top-level README file.

Run-Time Data

Run-time data consists of identities, policies, applications, and data objects used by the ForgeRock Identity Platform. You might extract sample run-time data while developing configuration data. Run-time data is volatile throughout ForgeRock Identity Platform implementation. Expect it to change even when the ForgeRock Identity Platform is in production.

You usually use sample data for run-time data. Run-time data that’s changed during development is not typically promoted to test and production environments. There’s no need to modify Docker images or restart ForgeRock Identity Platform services when run-time data is modified.

Examples of run-time data include AM and IDM identities, AM policies, AM OAuth 2.0 client definitions, and IDM relationships.

In the ForgeRock Identity Platform, run-time data is stored in databases and is not file-based. For more information about how run-time data is stored in AM and IDM, see: