PingCentral 2.0 (December 2023) - PingCentral - 2.0

Administrators can now synchronize OAuth, OIDC, SAML, and PingAccess templates to ensure that their templates are based on the most up-to-date configurations available. Applications based on out-of-date templates have Outdated Template icons displayed next to them, which inform application owners that newer versions of the templates are available.

Administrators can also now revert SAML SP connections and PingAccess application templates to previous versions. See the Reverting templates to previous versions tab on the SAML 2.0 and PingAccess templates page for details.

Note that when you upgrade to PingCentral 2.0, SAML and PingAccess application templates will have base revisions created for them. OAuth and OIDC templates created prior to version 2.0 cannot be synced with the most recent configurations available. Recreate the template in version 2.0 to use the sync feature going forward.

To accommodate a wide variety of promotion needs, application owners can now edit the application JSON for their applications when they promote them.

Note that providing application owners with this ability can be risky, so it’s highly recommended that approvals are enabled for the environment. Administrators can review the submitted application JSON and compare it to the original application JSON before approving the promotion request.

To prevent application owners from accidentally deleting applications from PingFederate (and PingAccess, when applicable) environments, you can enable a new option that allows only administrators to delete applications from the environment.

To help manage promotion approvals, both administrators and application owners can now hide promotion approvals that are in a canceled, promoted, or rejected status that display on the Promotion Approvals page when the Visible filter is used, which is enabled by default.

Administrators can add multiple approval expressions for an environment, which are evaluated sequentially from top to bottom in an IF/ELSE chain. Now, administrators can change the order in which these expressions display in the list by dragging and dropping them into different locations within the list instead of copying and pasting them between fields.

Previously, PingCentral was unable to handle a service provider (SP) connection with multiple Authentication Policy Contracts (APC) mapped within it. The PingCentral 1.14 release enables users to select from multiple mapped contracts when adding an application as a managed application or a template.

However, due to a known synchronization limitation, if you update an existing single APC SP connection already managed by PingCentral to include a second APC and subsequently synchronize the application, you won't find an option to specify your preferred APC.

To simplify your workflow and mitigate potential challenges, we recommend refraining from using synchronization to modify multi-APC connections. Instead, consider creating a new SP connection that aligns with your desired APC configuration. This approach grants you control over APC selection, ensuring a smoother and more efficient process.

PingCentral promotes access token mappings and authentication policy contracts (APCs) with OIDC applications, but the APC mappings that link the APCs to the access token managers are not currently promoted with them. If the APC mappings do not already exist in the target PingFederate environments, applications do not function as expected.

When new APCs are promoted in PingCentral, access token mapping referencing the APC is created, but persistent grant mapping is not established, so the configurations are invalid.

To resolve these issues, configure the APC mappings within PingFederate.

Customized authentication challenge responses, which support single-page applications, are available in PingAccess 6.2 or later. Applications with this type of policy can be added to PingCentral but cannot be promoted to another environment unless the authentication challenge policy, with the same UUID, also exists in the target environment.

When promoting SAML applications, PingFederate does not allow you to use the same certificate as both a service provider (SP) certificate and an assertion encryption certificate. Instead of preventing the promotion to continue, you receive a message similar to the following:

Environment'staging': PingFederate. This certificate either has the same ID or the same content as the certificate with index 0.

To continue the promotion, ensure that the SP certificate and the assertion encryption certificate are different.

After upgrading to 1.8, 1.9, 1.10, or 1.11, PingCentral fails to start if ${pingcentral.home} is used in the trust store path. To prevent this from happening, change the home path to be the absolute trust store path and delete the Certificates table in the database.

Templates created in 1.2 or earlier do not store the environment ID, so you cannot update their grant types, scopes, or policy contracts, nor can you revert them to previous versions.