PingOne Advanced Identity Cloud

Introduction to self-service promotions

PingOne Advanced Identity Cloud lets you run self-service promotions to move static configuration between a sequential pair of tenant environments, either from the development environment to the staging environment (staging promotion), or from the staging environment to the production environment (production promotion).

Non-sequential promotions (between the development environment and the production environment) are not supported.

If you promote configuration that accidentally causes instability or errors, Advanced Identity Cloud lets you run a self-service rollback to restore an upper environment to its previous configuration.

You can run a promotion or a rollback using the following options:

The Advanced Identity Cloud configuration model

The following video summarizes the concepts of the Advanced Identity Cloud configuration model:

Lower and upper environments

The environments in a sequential pair of environments are referred to as the lower environment (the configuration source), and the upper environment (the configuration destination); the terms lower environment and upper environment therefore refer to different environments, depending on which environment you are promoting to.

Standard promotion group of environments

For a standard promotion group of development, staging, and production tenant environments, the lower and upper environments are:

Development
environment
Staging
environment
Production
environment

Staging promotion

output lower

input upper

Production promotion

output lower

input upper

Key:

  • output lower = lower environment (configuration source)

  • input upper = upper environment (configuration destination)

Additional UAT environments

If you also have a UAT[1] environment in your promotion group of environments, it is inserted into the promotion process between the development and staging environments:

  • If you add one UAT environment, the revised lower and upper environments are:

    Development
    environment
    UAT
    environment
    Staging
    environment
    Production
    environment

    UAT promotion

    output lower

    input upper

    Staging promotion

    output lower

    input upper

    Production promotion

    output lower

    input upper

  • If you add two UAT environments, the revised lower and upper environments are:

    Development
    environment
    UAT
    environment
    UAT2
    environment
    Staging
    environment
    Production
    environment

    UAT promotion

    output lower

    input upper

    UAT2 promotion

    output lower

    input upper

    Staging promotion

    output lower

    input upper

    Production promotion

    output lower

    input upper

Environment locking

Locking an environment prevents configuration changes that could disrupt a promotion or a rollback; however, all authentication flows continue to work as normal.

Before you run a promotion or a rollback, you must lock the lower and upper environments. This prevents anyone else from locking either of those environments, which ensures only one promotion or rollback can be run at the same time in the same set of development, staging, and production environments.

Locking the lower and upper environments also blocks access to the ESV API in those environments. This prevents anyone else from accidentally disrupting a promotion or rollback by manipulating ESV configuration values. If the lower environment is also the development environment, then most Advanced Identity Cloud API endpoints are also restricted.

When a promotion or a rollback is complete, you must unlock the lower and upper environments to return the environments back to full functionality.

Configuration integrity checks

When you run a promotion or a rollback, Advanced Identity Cloud performs integrity checks on your static configuration to protect the stability of the upper environment.

Integrity check for missing ESVs

Promotion Rollback

Checked?

Yes

Yes

This integrity check looks for ESVs referenced in your static configuration, but not set in the upper environment.

Advanced Identity Cloud runs this integrity check on the whole configuration, not just configuration changes.

Integrity check for encrypted secrets

Promotion Rollback

Checked?

Yes

No

This integrity check looks for encrypted secrets embedded directly in your static configuration. It is best practice to store encrypted secrets in an ESV secret and update your configuration to reference the ESV secret instead.

Advanced Identity Cloud runs this integrity check on the whole configuration, not just configuration changes.

Promotion process FAQs (self service)

Can I partially promote configuration? Or promote the configuration for an individual realm?

Ping Identity promotes static configuration for the whole environment, so promotions always include all realms and all other static configuration. It is therefore not possible to promote partial configuration of any kind between environments, or promote the configuration for an individual realm between environments.

What kind of configuration changes can my company make?

Ping Identity considers configuration to be either dynamic or static.

Dynamic configuration

Dynamic configuration changes occur automatically when your application end users use Advanced Identity Cloud features. For example, when they configure applications or add users in the Advanced Identity Cloud admin UI, the changes take effect immediately in the development, staging, or production environments.

Dynamic configuration is not promotable.

Static configuration

Static configuration changes occur only when authorized administrators make changes in the development environment, or when configuration changes get promoted to another environment.

All static configuration is promotable.

The following tables summarize the types of configuration changes possible:

Identity Cloud UI Configuration

Feature Dynamic
(not promoted)
Static
(promoted)       

Custom domain names

  • DNS aliases

  • FQDN mappings

  • Cookie domains

  • Base URL service

Yes

Gateways & Agents

  • Native/SPA

  • Web (node.js, Java)

  • Service (m2m)

Yes

Applications

  • Provisioning applications

  • Bookmark applications

For OAuth 2.0 and SAML 2.0 applications, refer to [am_configuration].

Yes

Journeys

Yes

Custom themes

Yes

Identities

  • Connect (Connector Server)

  • Connect (Server Cluster)

Yes

Password policy

Yes

AM Configuration

Feature Dynamic
(not promoted)
Static
(promoted)       

Applications > Agents

  • IG Agent

  • Java Policy Agents

  • Web Policy Agents

Yes

Applications > Federation

  • Circle of Trust

  • SAML 2.0 Entity Provider

Yes

Applications > OAuth 2.0 (excluding scripts)

  • Clients

  • Remote Consent

  • Software Publisher

  • Trusted JWT Issuer

Yes

Authorization

  • Policy sets

  • Resource types

Yes

Scripts (all)

Yes

Services (per realm)

  • OAuth 2.0 provider

  • Social IdP services

  • Policy configuration

  • Base URL source

Yes

IDM Configuration

Feature Dynamic
(not promoted)
Static
(promoted)       

Managed objects:

  • Schema

  • Applications

Yes

Managed objects:

  • Assignments

  • Groups

  • Organizations

  • Roles

  • Users

Yes

Connector configurations

Yes

Sync mappings

Yes

Email notifications

Yes

How do we determine what is static and dynamic configuration?

Ping Identity considers all configuration static, except for the two types of configuration data that may be changed at runtime: applications and access policies. These config data types can be created on the fly, and can be used immediately afterwards.

Applications represented by OAuth2 clients can be registered at runtime through the Dynamic Client Registration Protocol. Access policies are created every time an end user shares access to a resource.

Ping Identity recognizes that other types of applications or access policies might not change at runtime. But Ping Identity products handle each data class consistently, so we can leverage potential usage patterns in the future.

What exactly is promoted and what is not?

These artifacts are NOT promoted. They remain unchanged during the promotion process:

  • Identities:
    Users, things, admins, roles, and assignments

  • Applications:
    Gateways and Agents

  • Access policies:
    AM policy sets and resource types

All other configuration can be promoted between environments.

How do I manage configuration?

You have the choice of using the Advanced Identity Cloud admin UI, or using the REST APIs for configuration.

Dynamic configuration
  • You configure applications and add users in your development, staging and production environments.

  • Changes take effect immediately.

Static configuration
  • You make changes in your development environment.

  • You promote it to staging or production when you are ready.

What if I need to revert configuration?

Static configuration is maintained in Git repositories within each of your environments. So, configuration can be restored as a whole to previous settings.

You may need to revert static configuration for these reasons:

  • You promoted configuration that caused instability or errors and want to restore the upper environment to the previous configuration.

    In this case, you can run a self-service rollback using the API. Refer to Run a rollback.

  • You made experimental configuration changes in your development environment. Despite reasonable efforts to reverse them, you haven’t succeeded and want to return to a stable configuration.

    In this case, you can raise a ticket to Backstage Support to revert the configuration of your development environment to the safest backup point before the time you specify. Refer to Revert configuration in your development environment.

Dynamic configuration is not altered when reverting static configuration. Users, applications, and access policies remain as they are.

How long does the promotion process take?

Promotions normally take 10–45 minutes.

What if some configuration attributes must vary per environment?

We understand that sometimes you have to use a configuration attribute value that is not identical across development, staging, and production environments. For example, you might need one set of credentials for an external service in the development environment, but a different set of credentials in the production environment.

Refer to Define and promote an ESV for an explanation of how this type of configuration is handled.

Copyright © 2010-2024 ForgeRock, all rights reserved.