PingCentral

Promotion processes

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 doesn’t 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, you can revert them to previously promoted versions. The reverted version of the application won’t exist outside of PingCentral until it’s promoted again, at which point it’s also available in PingFederate or PingAccess. For details, see Reverting applications to previously promoted versions.

  • OAuth and OIDC promotions

  • SAML SP promotions

  • PingAccess promotions

OAuth and OIDC application promotions

When promoting OAuth and OpenID Connect (OIDC) applications, application owners provide this information:

  • Redirect URIs: The trusted location that the application is 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 doesn’t already exist, PingCentral creates all of the items defined in the application JSON, along with the information that the application owner provided.

If the Allow JSON editing for application promotions option is enabled for the environment, application owners are able to edit the underlying application JSON when they promote their OAuth client applications.

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’re defined as exclusive scopes and are associated with the client upon promotion.

While PingCentral does not 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(s): The application’s URL to which SAML assertions from the identity provider are sent after user authentication occurs.

  • SLO Service URL(s): the application’s URL utilized for single logout (SLO) functionality.

  • Attribute mapping information: The application attributes are 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.

Alternatively, they can provide the Entity ID, ACS URL, and certificates during the promotion process.

If the Allow JSON editing for application promotions option is enabled for the environment, application owners are able to edit the raw JSON when they promote their SAML SP applications.

Application owners are also asked to provide a signing certificate during the promotion process. They can select an existing PingFederate signing certificate, or the environment default certificate, if one exists. The default certificate is the certificate added to the environment when it was created or last updated. If signing certificates are not available in the PingFederate environment and an environment default certificate is not available, or if an environment default certificate is available but expired, they can choose to automatically generate a certificate.

To learn more about this process, see Promoting SAML applications in the PingCentral for Application Owner’s 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.

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 isn’t 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.

Reverting applications to previously promoted versions

When you revert applications to previously promoted versions, the reverted versions of the application will not exist outside of PingCentral until you promote them again, at which point they will also be available in PingFederate or PingAccess.

Steps

  1. On the Applications page, locate the application you want to revert to a previously promoted version.

    You cannot revert applications created in previous versions of PingCentral.

  2. Click the expandable icon associated with the application, select the Promote tab, and then click View Details.

  3. In the Promotion Details window, click Revert Application.

    Result:

    A message displays asking you if you are sure you want to revert this application.

  4. Click Revert.

    Result:

    The reverted version of the application displays in your applications list.

    Reverting OAuth and OIDC applications to previously promoted versions overrides client secrets, so you will need to create or generate new secrets before you promote them again. Reverting SAML applications to previously promoted versions overrides the Entity IDs, ACS URLs, and certificates, so you might need to update this information before you promote them again.