These early access features are available for preview purposes only, and are not covered under standard Support SLAs. You can open support cases for feedback, bug reports, configuration questions, or other inquiries related to early access features, but resolution times for these cases will vary. These cases often require collaboration with our Engineering and Product teams, so timelines might exceed the usual SLAs for your Support package.

We encourage you to use any of the early access features you find applicable. You'll need to enable each feature you'd like to use. See Early Access Features for instructions.

The Configuration Management service gives you a secure and flexible approach to automating (promoting) configurations across multiple environments, enabling the seamless creation, updating, and deletion of resources while supporting dynamic configurations through variable management. Resource dependencies are maintained, ensuring smooth cross-environment transitions and promotions. Auditing and reporting enhance oversight and compliance.

To use the Configuration Management service you need to have the Environment Admin role for at least two environments. The general workflow is:

• Select configurations that you want to promote from one environment to another (generally, through development, testing, and production stages).
• If desired, use promotion variables to dynamically substitute different property values for a configuration resource included in a promotion operation.
• Execute the promotion plan returned by the Read One Promotion or Read All Promotions to move the configuration from the source environment to the target environment.

The Configuration Management service is comprised of these sub-services:

• Snapshots
• Promotions
• Promotion Variables
• Promotion Configuration

Resources requiring special handling

Certificates

Certificates are not a promotable resource in PingOne, however special handling of them is required for resources that reference them. Certificate references can be promoted in using either default certificates or through the use of promotion variables:

• Default certificates

  When a configuration resource is using the default certificate as its signing key (a SAML application, for example), the application can be promoted, and will reference the default signing key existing in the target environment. Certificate rotation for the signing key can be done by setting a new default certificate in the target environment, and then promoting the configuration resource or resources using the default signing key in the source environment.

• Certificates as promotion variables

  You can handle all certificate references other than default certificates using promotion variables. You'll need to create a promotion variable with the certificate ID in each environment. When the resource or resources referencing the certificate are promoted, the promotion operation will use the variable value to substitute the correct certificate in the target environment or environments. If there are other configuration resources that use the certificate, they will also use the correct certificate when any of these configuration resources are promoted to the same target environment or environments.

Attributes

You can promote individual attributes in the schema. However if you're promoting an application that references a custom attribute, the promotion plan will include all attributes in the schema. In this case, you can then exclude the unnecessary attributes by editing the promotion plan prior to starting the promotion operation.

If you want to use Postman

You can download or fork the Postman collection for the early access Configuration Management APIs, and test them in your Postman environment. If you don't already have a Postman installation, you can install the free version. See Download Postman.

Import or fork the Postman collection PingOne Configuration Management APIs - Early Access into your Postman installation by clicking the Run in Postman button below:

Refer to Postman and the PingOne APIs for more information.

A snapshot is a point in time representation of any configuration resource in PingOne. A snapshot is triggered when the request POST {{apiPath}}/environments/{{envID}}/snapshots is called. The configuration resource, and optionally all of its dependencies, are then stored by the Snapshot service. The snapshots are stored and indexed using the original identifier (ID) of the configuration resource. For example, an applications snapshot will be stored using the ID of the application. Subsequent calls to the request POST {{apiPath}}/environments/{{envID}}/snapshots for the same configuration resource generates a new version of the configuration resource each time the request is called. You can retrieve the version history of any configuration resource using the original identifier of the resource. You'll use the snapshot created for a configuration resource to promote (apply) the configuration resource from the source environment to another environment.

Snapshots data model

A promotion includes, at a minimum, source and target environment references, automatically generated source and target snapshots, the resource or resources to promote to the target environment, and a promotion plan for the promotion operation. You need to have the Environment Admin role for both the source and target environments. You can optionally include a specific source environment snapshot to use, as well as a mapping of the source environment configuration resource or resources to the target environment configuration resource or resources.

A PingOne admin having Environment Admin permissions can review the promotion plan, and update the promotion mapping and variable definitions or declarations as needed. The promotion plan is then regenerated based on the updates. Use the Read One Promotion or Read All Promotions to view the promotion plan.

If you do not set any promotion variables, the configuration resource or resources that you specify for the source or target environment will be used as is, and cannot be changed during the promotion operation. See Promotion Variables for more information.

When you choose to start the promotion operation, the promotion plan supplies the promotion operation instructions to the Promotions service. The Promotions service then:

• Filters out any configuration resources that haven't changed, and calls the required target environment API using the new or altered resources.
• Sets the promotion's started_at and status values.
• Collects any errors into a JSON array, and returns the errors.
• Updates the promotion's completedAt and status values when the promotion operation is complete.

Promotions data model

Currently, not all resources, services, or products can be used in a promotion operation.

Excluded products or services

• PingOne DaVinci (except for Forms)
• PingOne Authorize

Excluded resources

Some resources can never be promoted, while others will be supported for promotion, but currently are not.

Permanently excluded resources

These resources are expected to never be supported for promotion:

• Active Identity Counts
• Activities
• Adaptive Trust Policies
• Applications Role Assignments
• Application Signons
• Application Signons Statistics
• Certificates
• Connectors
• Dashboards
• Data Exploration Batches
• Data Explorations
• Data Exploration Templates
• Licenses
• Licenses Expires At
• Licenses Metrics Active Identity Counts
• Licenses Name
• PingOne for Enterprise Orchestrations
• PingOne for Enterprise Callback

Currently excluded resources

These resources will be supported for promotion, but are not currently:

• Admin Config
• API Servers
• Application Entitlements
• Application Permissions
• Application Resources
• Application Roles
• Applications Secret
• Authorization Attributes
• Authorization Changes
• Authorization Conditions
• Authorization Connector Templates
• Authorization Policies
• Authorization Processors
• Authorization Rules
• Authorization Services
• Authorization Statements
• Branding Settings
• Connector Instances
• Credential Counts
• Credential Issuer Profile
• Credential Types
• Custom Domains
• Davinci Applications
• Decision Endpoints
• Delegated Admins
• Device Authentications
• Digital Wallet Applications
• External Services
• Fido Devices Metadata
• Flow Definitions
• Flow Metadata
• Flow Policies
• Flows
• Fraud Evaluations
• Fraud Events Details
• Fraud Feedbacks
• Fraud Sessions
• Identity Cloud
• Identity Cloud Orchestrations
• Images
• Integrations
• Languages
• Legacy
• Locales
• Metrics
• Migrate
• Notification Callback
• Notification Callback AWS email
• Notification Callback Syniverse
• Notification Callback Twilio
• Notification Callback Whatsapp
• Notifications
• Notifications Quota
• OAuth Jobs
• OAuth Tokens
• Organization Quota
• Password Storage Scheme Config
• Pingid
• Pingid Mobile App Versions
• Pingid Mobile Display Names
• Pingid Mobile Os Versions
• Portal
• Presentation Sessions
• Promotions
• Promotion Variable Declarations
• Propagation
• Propagation Mappings
• Propagation Plans
• Propagation Provisioning Syncs
• Propagation Revisions ID
• Propagation Revisions ID Latest
• Propagation Rules
• Propagation Store Metadata
• Propagation Stores
• QS Dashboards
• Rate Limit IP Configs
• Recaptcha V2 Config
• Resources Secret
• Risk Evaluations
• Risk Feedback
• Roles
• Seen Devices
• Sessions
• Snapshots
• Software Licenses
• Solutions
• Subscriptions
• Tiles
• Total Identities
• Translations
• Users
• Variables
• Voice Phrases

Use promotion variables to to account for environment-specific differences, such as 3rd party integrations or URLs. You can specify configuration resource property values for either the source or target environment to be substituted for existing property values by the promotion operation. Only the promotion variables you set can change property values for use by the promotion operation. If you do not set any promotion variables, the configuration resource or resources that you specify for the source or target environment will be used as is, and cannot be changed during the promotion operation.

To use promotion variables, you need to:

1. Specify the configuration resource to be promoted in a snapshot.
2. Define the variable or variables to be used for a source or target environment configuration resource property. See Variable Definitions.
3. Declare the variables to be used by the promotion operation. See Variable Declarations.

A few things to be aware of:

• The variables are scoped only to the specified configuration resources, and are not applied to any dependent resources.
• Variables are not versioned with a snapshot, so for each promotion operation, you need to ensure the variable settings for a configuration resource are correct.
• Any configuration resources that you change directly without updating the variables will be overwritten by a subsequent promotion operation. This is because the promotion operation will use the existing variable set.

Not all configuration resources or properties can be used as promotion variables. Here's the listing of configuration resources, and the associated properties that are supported as promotion variables:

When promoting a configuration, you need to define any variables you intend to use to substitute for existing property values. Once defined, you'll need to then declare a variable. See Variable Declarations for details.

Variable definitions data model

Before you can declare a variable (POST {{apiPath}}/environments/{{envID}}/promotionVariableDeclarations), you need to define the variable that you intend to use. See Variable Definitions for details.

Variable declarations data model

The promotionConfiguration endpoint sets and reads default target environment to be used for promotions. When you know that you'll be working with a specific target environment, you can set this environment as the default for the promotions you're doing.

PingOne Authorize provides customers with a fine-grained, attribute-based, dynamic authorization decisioning capability. PingOne Authorize moves per-transaction authorization logic from customer applications to PingOne, enabling centralized control of authorization policy and reuse of policy across applications and contexts.

The PingOne Authorize Admin API endpoints in this section include:

• PingOne Authorize Trust Framework
• PingOne Authorize Editor Policy Management

For PingOne Authorize introductory information, see Introduction to PingOne Authorize in the PingOne Authorize administrators guide.

If you want to use Postman

You can download or fork the Postman collection for the early access PingOne Authorize Editor Policy Management APIs, and test them in your Postman environment. If you don't already have a Postman installation, you can install the free version. See Download Postman.

Import or fork the Postman collections for PingOne Authorize Admin APIs - Early Access into your Postman installation by clicking the Run in Postman button below:

Refer to Postman and the PingOne APIs for more information.

The PingOne Authorize trust framework service provides endpoints to define the entities and configurations to target policies and rules when making dynamic authorization requests.

The trust framework is based on attributes. These attributes have resolvers which bring contextual data values into the attribute. Resolvers can be conditional using an embedded condition or they can be a reference to a condition entity.

A service resolver references a service that can call out to a third-party HTTP service or the PingOne Protect service. Attributes can transform the value received from resolvers using embedded processors or referenced processors.

To create and manage the attributes, services, conditions, and processors, required by the PingOne Authorize trust framework, see:

• Authorization attributes

  Provides endpoints to create, read, update, test, and delete trust framework authorization attributes.

• Authorization services

  Provides endpoints to create, read, update, test, and delete trust framework authorization services.

• Authorization conditions

  Provides endpoints to create, read, update, test, and delete trust framework authorization conditions.

• Authorization processors

  Provides endpoints to create, read, update, and delete trust framework authorization processors.

• Authorization connector templates

  Provides an endpoint to read trust framework authorization connector templates.

Authorization attributes provide contextual information that informs fine-grained dynamic authorization decisions. Attributes have the following characteristics:

• An attribute has zero or more resolvers that bring the contextual data into the attribute value. The list of ordered resolvers are evaluated sequentially until a successful value is returned.

• An attribute has zero or more processors that transform the data coming from the resolvers.

• An attribute has a valueType property value that specifies the final output type of the attribute.

Authorization attributes data model

Authorization attributes resolvers type data model

Event types

The audit reporting events applicable to the authorize attribute service are:

Response codes

Authorization services, also referred to as Policy Information Points or PIPs, represent third-party HTTP services or internal PingOne platform services (such as PingOne Protect) that may be called to retrieve data.

These endpoints provide operations to create, read, update, test, and delete authorization services.

Authorization services data model

The serviceType property supports the following three options: NONE, HTTP, and CONNECTOR. The NONE option does not require additional configuration. The HTTP and CONNECTOR service types require additional configuration property values in the request. The following tables describe the data models for these options.

HTTP serviceType data model properties

If the serviceSettings.type property is HTTP, the service supports the following service settings properties:

BASIC

TOKEN

CLIENT_CREDENTIALS

CONNECTOR data model properties

ATTRIBUTE

INPUT

Event types

The audit reporting events applicable to the authorization services service are:

Response codes

Conditions in PingOne Authorize define authorization logic by comparing one thing to another. Conditions evaluate to either true or false. The authorization conditions service provides endpoints to create, read, update, test, and delete trust framework authorization conditions.

Authorization conditions data model

Authorization conditions condition type data model

Event types

The audit reporting events applicable to the authorization condition service are:

Response codes

Authorization processors transform the data coming from the resolvers. Processors manipulate and transform data, including extracting details from structured data, or converting data to different formats. These endpoints provide operations to create, read, update, and delete authorizaton processor resources.

Authorization processors data model

Authorization processors processor type data model

Event types

The audit reporting events applicable to the authorize processors service are:

Response codes

This endpoint provides an operation to view the authorization connector templates associated with the specified environment.

Connector templates data model

Response codes

PingOne Authorize policies model business requirements into authorization logic using elements created in the PingOne Authorize Trust Framework.

Policies are based on application requirements and the regulations that you're complying with. Your organization imposes many conditions and constraints on access control. Policies capture these constraints in rules that define the circumstances under which users can access certain resources.

The policy management endpoints include:

• Authorization policies

  Provides endpoints to create, read, update, test, and delete authorization policies.

• Authorization statements

  Provides endpoints to create, read, update, and delete authorization statements.

• Authorization rules

  Provides endpoints to create, read, update, test, and delete authorization rules.

Authorization policies specify the statements (directives that instruct the policy decision service to perform additional processing in conjunction with an authorization decision), conditions (authorization logic comparing one thing to another), and combining algorithms (the process for combining multiple rules) to determine an authorization decision.

Authorization policies data model

Authorization embedded policies data model

Authorization policies embedded rules data model

Event types

The audit reporting events applicable to the authorize policies service are:

Response codes

Statements instruct the policy decision service to perform additional processing in conjunction with an authorization decision. In addition to allowing or blocking access to a resource, using statements, the decision service can attach information to decision responses and filter and transform API payloads.

Authorization statements data model

Event types

The audit reporting events applicable to the authorize statements service are:

Response codes

Rules in PingOne Authorize identify the statements and conditions by which a decision node is evaluated. If the condition is true, the decision node is evaluated. Otherwise, it is not. PingOne Authorize policies can combine multiple rules to produce a Permit, Deny, Indeterminate, or Not Applicable decision.

Authorization rules data model

Event types

The audit reporting events applicable to the authorization rules service are:

Response codes