About Data Used by the Platform

This documentation describes new, pre-release CDK features. If you want to work with a stable feature set, use the CDK as described in this section of the documentation.

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.

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:

Configuration Profiles

A ForgeRock Identity Platform configuration profile is a named set of configuration data and selected AM run-time data that describes the operational characteristics of a running ForgeRock deployment. A configuration profile can have three types of data:

  • The AM file-based configuration.

  • Certain AM run-time data:

    • OAuth 2.0 clients

    • OpenID Connect 1.0 clients

    • IG, Web, Java, and SOAP STS agents

    • Policies

    • SAML v2.0 circles of trust and entities

  • The IDM file-based configuration.

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 export configurations from the running CDK to the staging area before building a custom 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.

To create a custom Docker image for the platform, you:

  • Configure the AM and IDM services running in the CDK using their UIs and APIs.

  • Export configuration data from the running CDK to the staging area.

  • Save configuration data in the staging area to a configuration profile in the master directory, and manage the profile using Git commands.

  • Run Skaffold to build the custom Docker images.

For more information, see the sections that contain detailed instructions for building the AM, Amster, and IDM Docker images.

Next Step