Specific changes in PingAccess might require additional steps during an upgrade to the latest version.
With continued product and hardware security module (HSM) integration improvements, customers should migrate off of Java 8. Ping Identity removed Java 8 support from the qualification process in December 2023. For more information, including Java 11 support, see Installation requirements.
Microsoft Internet Explorer 11
Ping Identity commits to deliver the best experience for our administrators and users. As we continue to improve our products, we encourage our customers to migrate off of Microsoft Internet Explorer 11. As of December 2021, we no longer include Internet Explorer 11 in our qualification process.
Performing a zero downtime upgrade from 6.0, 6.0.1, 6.0.2, or 6.0.3 to a later version
If you are using PingAccess 6.0, 6.0.1, 6.0.2, or 6.0.3, zero downtime upgrades to later versions can fail due to PKCE changes.
To prevent this issue, edit your existing web sessions and enable PKCE support.
- Click Access and then click .
- Expand the web session and click .
- Click Show Advanced.
- Click Enable PKCE.
- Edit the web session. Click Save.
- Repeat these steps for each web session.
New templates for error and logout pages
PingAccess 6.1 updated several error and logout page template files to modernize their appearance and remove Ping branding:
For more information about the templates, see User-facing page customization reference. If you have previously customized the template files, you can re-customize them using the new files.
Using a proxied PingFederate deployment
PingAccess 6.2 Beta introduced the ability to configure a proxied PingFederate deployment through PingAccess. If you have manually configured a similar deployment in an earlier version of PingAccess, you can continue to use it.
If you plan to switch, review the configuration options in the proxied PingFederate deployment UI to verify that it can manage the use cases of your current configuration, and remove any PingFederate-related applications before migrating the configuration.
The SPA support check box was removed from the Admin UI for web type applications in PingAccess 6.2. As a result, all web type applications created in the admin UI in PingAccess 6.2 and later have SPA support enabled by default. The SPA support check box is still available for API type applications and Web + API type applications. For more information, see Application field descriptions.
If the default settings for SPA support with web type applications aren't compatible with your environment or with a specific application, create an authentication challenge policy to replace these settings and achieve the desired behavior. For more information, see Configuring authentication challenge policies.
Runtime state clustering removal
Support for runtime state clustering was removed in PingAccess 7.0. However, one benefit of runtime state clustering was that it enabled rate limiting rules to behave more consistently in a clustered environment. This was because runtime state clustering enabled all of the engines in a cluster to know the total number of requests for a resource, not just the requests which that engine received.
If you're using runtime state clustering with rate limiting rules, before upgrading to PingAccess 7.0 or later, you should either:
- Configure a load balancer sitting in front of a PingAccess cluster to stick the session to a specific engine. This ensures that a single PingAccess engine node applies the rate limiting rule. For more information, see Load balancing strategies.
- Tune down the Max Burst Requests interval on the rate limiting rule, following the <current max burst requests interval>/<number of engines in cluster> ratio.