PingCentral 1.14 (September 2023)
New features and improvements in PingCentral 1.14.
Disable environments when down for maintenance or offline
New
PingCentral administrators can now disable referenced PingFederate environments for any reason, such as PingFederate being unavailable due to maintenance tasks. Additionally, we added a new environment status bar that indicates if an environment is offline. In such cases, application owners will receive a notification indicating that the environment is disabled or offline rather than encountering a UI error. For more information, see step 1 of the Updating environments tab in Managing environments.
Import SAML Connection to PingCentral from PingFederate with attributes mapped to data source
New
All attributes defined in a SAML SP connection are now integrated into the PingCentral application. This enhancement eliminates a limitation and is expected to enhance usability significantly. For more information, see step 3 in Using SAML 2.0 templates.
Additional synchronization capabilities
New
We added the ability to effortlessly initiate an application synchronization in PingCentral. Now, when you make external modifications to an application configuration, you can seamlessly update the application information within PingCentral. This removes the need to manually update application information and introduces a more streamlined and efficient process. For more information, see step 2 in Updating applications.
Other improvements
New
-
We also updated the following bundled components and third-party dependencies:
-
Apache Commons Text 1.10
-
H2 database migration when the installation path has any spaces
Fixed
We resolved an issue where H2 database migration fails during an upgrade if there are spaces in the installation path for the existing or new instance.
SSO inactivity sign off
Fixed
We fixed an issue where utilizing single sign-on (SSO) to access the PingCentral console incorrectly triggered a timeout based on an ID token’s lifetime.
Multi-APC connection synchronization
Issue
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.
Configure APC mappings for OIDC applications in PingFederate
Issue PingFederate
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.
Promoting applications with authentication challenge policies
Issue PingAccess
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.
SP certificates and assertion encryption certificates must be different
Issue PingAccess
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': {pingfed}. 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.
Update truststore path if PingCentral fails to start
Issue
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.