PingCentral 1.12 (June 2023) - PingCentral - 2.0

Previously, PingCentral did not allow an administrator to require approval for a non-administrator to promote an application to an environment. As of now, administrators can use Spring Expression Language (SpEL) based rules to trigger an approval requirement if an expression is or isn't met. Administrators will find a bell icon indicating active approval requests, and developers are informed when their requests are approved. For more information, see Managing approvals (administrators).

Administrators can now enforce a strong client secret for applications by requiring that PingCentral generate the client secret. With this feature enabled, when developers promote an application, they won’t be able to create a client secret manually. This avoids the usage of weak client secrets. For more information, see Managing environments.

When promoting SAML applications, developers can adjust and configure single logout (SLO) URLs. This adds flexibility and removes the need to manage multiple SAML applications only because different SLO URLs are required. For more information, see Promoting SAML applications.

We added support for Java Development Kit (JDK) 17.

To set up a service provider (SP) connection, PingCentral now accepts SAML metadata files exported from other SP connections. These files are used to extract the following information: entity IDs, ACS URLs, SLO service URLs, certificates, and attributes.

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.