PingCentral makes it possible for application owners to promote their OAuth, OpenID Connect (OIDC), SAML, and PingAccess applications to development environments themselves.
After applying the templates to their applications, application owners enter information about their target environments into PingCentral and promote their applications to the designated environment.
The templates contain the raw JSON from the model applications on which the templates were based. Although PingCentral saves this information, it does not modify it. Instead, the saved JSON is used as a starting point for creating new applications and is modified only in memory with the environment-specific information during the promotion process.
After an application is promoted, application owners can revert them to previously promoted versions. The reverted version of the application will not exist outside of PingCentral until it is promoted again, at which point it will also be available in PingFederate or PingAccess. For details, see Reverting applications to previously promoted versions.
OAuth and OIDC application promotions
When promoting OAuth and OIDC applications, application owners provide this information:
- Redirect URIs: The trusted location that the application will be redirected to with the authorization code or access token after the OAuth flow is complete. Redirect URIs are only required when promoting applications that use an authorization code and implicit grant types.
- Client secret: Used if a client secret is required to authenticate the application. Application owners can generate a client secret or create one of their own.
To learn more about this process, see Promoting OAuth and OIDC applications in the PingCentral for Application Owners guide.
During the promotion process, the application name and description remains the same. If PingCentral identifies an identical client in PingFederate, the application JSON, along with the information that the application owner provides, overwrites the PingFederate OAuth client within the target environment. If the client does not already exist, PingCentral creates all of the items defined in the application JSON, along with the information that the application owner provided.
If OAuth clients have ATMs, OIDC policies, or scopes that conflict with the target environment during the promotion process, PingCentral does not change them because they could be shared across clients. Otherwise, PingCentral adds the ATMs, OIDC policies, and scopes specified in the original JSON file. If scopes are added, they are defined as exclusive scopes and are associated with the client upon promotion.
While PingCentral does not yet promote the policy contract to persistent grant mappings, it promotes all access token mappings associated with the client, which are determined by the access token managers associated with the client. Only access token mappings that use the default, client credentials, or authentication policy contract contexts will be promoted.
SAML SP application promotions
When application owners add an application to PingCentral, they can provide an .xml file that contains service provider metadata from a similar SAML application. This file might contain any or all of these items:
- Entity ID: Uniquely identifies the application.
- ACS URL: The application's URL to which SAML assertions from the identity provider is sent after user authentication occurs.
- Attribute mapping information: The application attributes mapped to the identity attributes required to fulfill the authentication policy contract in PingFederate.
- SP public certificate: Used to prove ownership of a public key and obtained from the service provider.
- Assertion encryption certificates: Used to prove that the SAML assertion is encrypted.
Or, they can provide the Entity ID, ACS URL, and certificates during the promotion process.
To learn more about this process, see Promoting SAML applications in the PingCentral for Application Owners guide.
During the promotion process, the application name and description remains the same. If PingCentral identifies an identical connection in PingFederate, the application JSON, along with the information that the application owner provides, overwrites the PingFederate connection within the target environment. If the connection does not already exist, PingCentral creates items defined in the application JSON, along with the information that the application owner provided.
PingCentral generates a self-signed IdP certificate with a 1-year expiration for each application and environment. This certificate cannot be uploaded, selected, or rotated in this release. If a connection is re-promoted, the same certificate is used and orchestrated to PingFederate.
PingAccess application promotions
The information required to promote PingAccess Web applications, API applications, and Web + API applications to PingAccess environments varies by type and includes:
- Virtual host: The public-facing host name and host port required to promote all applications. For example, den.ping.com:8443.
- Access validation method: If the application is an API or Web + API application, owners can specify the access validation method, whether it be a token provider or a token validator, if appropriate.
- Web session: If the application is a Web + API application, owners are required to select a Web session from a drop-down list. This information is not required to promote Web or API applications.
- Identity mapping: Owners can select identity mappings from drop-down lists for Web, API, and Web + API applications.
- Site or Agent name: Owners specify the name of the site for gateway deployments and the name of the agent in an agent deployment.
To learn more about this process, see Promoting PingAccess applications in the PingCentral for Application Owners guide.