PingAccess 7.3 (June 2023) - PingAccess - 7.3


PingAccess 7.3

Upgrading from PingAccess 6.2 or below to the latest version will require two steps as of PingAccess 8.0


Beginning with the PingAccess 8.0 release in December 2023, upgrades to the latest release directly from PingAccess 6.2 and below won’t be possible. You'll need to upgrade to a version of PingAccess between 6.3 and 7.3 first, and then upgrade to the latest version of PingAccess.

Added support for IBM HTTP Server running on RHEL 8 or 9


Added support for IBM HTTP Server 9.0 running on RHEL 8 or 9 to the PingAccess agent for Apache (RHEL). For more information, see:

Added UI controls for risk policy configuration


Added two new pages in the administrative console, PingOne Connections and Risk Policies, as well as new configuration options on the Application and Application Resource tabs. These UI controls simplify the process of setting up a PingOne Protect integration. For more information, see the following topics:

Adjust log levels through the administrative console or API


Added a log4j-categories.xml file which defines and allows references to PingAccess-specific logging categories. This enables you to adjust log levels through the administrative console or API as opposed to directly within the log4j2.xml file.


If you have customized your log4j2.xml file, you must merge it with the log4j-categories.xml file to be able to reference the new categories.

To adjust log levels in the administrative console, use the new Log Settings page to enable Verbose logging on a per category basis. In the administrative API, enable verbose logging through the new /logSettings endpoint. For more information on log levels and how to adjust them, see Log settings.

Apply PingAuthorize rules on web applications


Previously, two PingAccess rule types, the PingAuthorize access control rule and the PingAuthorize response filtering rule, could only be applied on API applications.

You can now apply either rule type on a web application, Web + API application, or a specific web application resource through the PingAccess administrative console or administrative API. This enables you to apply rules configured in PingAuthorize to inbound web requests and outbound web responses in PingAccess.

Upgraded AWS CloudHSM Client SDK 3.x to 5.x


Removed support for AWS CloudHSM Client SDK 3, which was limited to usage with Java 8 and Linux. Added support for AWS CloudHSM Client SDK 5, which is usable with Java 8 or Java 11, and can be deployed on Linux or Windows.

However, Client SDK 5 also introduces an issue with elliptic curve key pairs which prevents them from being assigned to PingAccess listeners. For more information on Client SDK 5, see Adding an AWS CloudHSM provider and Upgrade considerations.

Track id_token or include the id_token_hint parameter in SLO calls


Added a new configuration option for common token providers and a new configuration option for administrative console UI SSO authentication:

  • Select the Track id_token check box to track the id_token that the authorization server provides after authentication. For more information, see Configuring OpenID Connect token providers.

    You must select Track id_token to use the id_token attribute when Creating header identity mappings.

  • The Include id_token_hint in SLO check box lets administrators choose whether to send an id_token_hint in PingAccess's single logout (SLO) request to the token provider. This extends PingAccess’s compatibility with token providers that require this parameter for SLO, such as Okta. For more information, see Configuring admin UI SSO authentication.

Selecting either of these options increases the size of the PingAccess cookie. For more information on other settings you can adjust to balance this out, see Minimizing the PingAccess cookie size.

Use a SAML Token Mediator to perform token mediation


Added a new type of authentication to the Site Authenticator list in the administrative console, SAML Token Mediator. This authentication type enables PingAccess to perform token mediation with PingFederate to get a SAML 1.1 or SAML 2.0 assertion, providing greater flexibility in the types of security tokens that you can use.

For more information, see Adding site authenticators and SAML token mediator site authenticators.

Use environment variables to simplify container management


Simplify container management by using environment variables to override the values of PingAccess configuration properties instead of directly editing each property in its respective .properties file.

  • You can only override the value of a property defined in one of the property files from the <pa>/conf directory.
  • If you're running PingAccess in a clustered deployment, you must apply environment variable changes to each cluster node individually.

For more information, see Use environment variables to override configuration settings.

Connect engine nodes to a more recently upgraded administrative node


Engine nodes and the replica administrative node running PingAccess 7.3 or later can now connect with an administrative node that’s running a later version of PingAccess. This change:

  • Reduces the possibility for outages caused by outdated information.
  • Improves stability for containerized deployments.
  • Reduces log error messages.
  • Improves the process of upgrading to future versions of PingAccess.

Currently, only nodes from PingAccess 7.3 or later can replicate data that's relevant to the version they're running.

The ability to replicate version-relevant data does not remove any steps from the upgrade or zero-downtime upgrade process. You should still finish upgrading all of an environment's nodes before making configuration changes.

For more information, see Upgrade considerations.

Self-register a replacement engine if an existing engine isn't running


Added a new cluster configuration setting to the file, engine.polling.test.delay. This property provides more handling flexibility if an engine can't connect to the administrative node.

If a previously existing engine isn’t running, a replacement PingAccess engine that's created with the same name can now self-register. The replacement engine also updates its configuration to match the configuration from the most recent registration JWT.

Control whether a replacement engine will self-register when this condition is met with the engine.polling.test.delay property. Set this value below zero if you don’t want engines to self-register, and set it equal to or higher than the engine.polling.delay value to increase flexibility in determining whether an previously existing engine is running. For more information, see Configuration file reference.

Use additional matching strategies on web session attribute rules


Added a new selector to web session attribute rules, Matching Strategy. To change how PingAccess evaluates attributes, select an option from this list. By default, PingAccess uses a Case-Sensitive matching strategy.

Evaluate attributes with a Case-Insensitive or DN Matching strategy to make changes at the attribute source that are semantically equivalent for the source context without having to modify your PingAccess configuration. This reduces the possibility of outages caused by case-sensitivity differences in policy evaluation.

For more information, see Web session attribute rule.

Upgraded admin API documentation to use OAS 2.0


In PingAccess 7.3, the Swagger-UI component that displays the PingAccess admin API documentation was upgraded to remove outdated dependencies. The Swagger-UI component now uses OpenAPI specification (OAS) 2.0. For more information, see Administrative API endpoints.


The specification that the PingAccess admin API docs used previously, Swagger 1.2, has been deprecated. The Swagger 1.2 specification is still available at https://<PA_HOME>:<PORT>/pa-admin-api/v3/api-docs/pa/api-docs.json, but might be removed from future versions of PingAccess.

Expanded verbose logging categories


Added two new log categories to the Log Settings page in the administrative console, Core and Cluster Replication. For more information on these categories, see Log level category descriptions.

Updated PingAccess client authentication logic


Updated the PingAccess logic that determines which authentication method to use at runtime. This update prevents errors when Private Key JWT and Mutual TLS are the only client authentication methods that a token provider can support.

Added an option for access token validators to skip audience validation


Added a Skip Audience Validation check box to the Access Token Validator page in the administrative console. If this option is selected, an access token validator doesn’t attempt to validate access tokens for audience claims.


You must select this option if you don't plan to configure an audience value. For more information, see Adding access token validators.

Improved Windows request processing speed


A setting in the upgrade utility and PingAccess Service/conf directory,, was slowing request processing. This setting is specific to Unix environments, so it was removed from Windows script/conf files in PingAccess.

PingOne risk policy integration maps user-agent header manually


PingAccess wasn't sending the browser.userAgent parameter to PingOne Protect because PingAccess doesn't currently support device profiling (which would normally collect this parameter). In the absence of device profiling, PingAccess now attempts to map this parameter manually and send it to PingOne Protect.

Redirect and templated authentication challenges now set PingAccess cookies


PingAccess now proactively sets web session cookies for Redirect and Templated authentication challenges when you select the Append Redirect Parameters check box on one of those two challenge generators. Adding web session cookies helps the frontend application to interpret redirect or templated challenge responses and begin the appropriate authentication procedure.

Improved vague error response message when PingOne Credential is blank or null


The response message PingAccess returns for errors generated when an administrator adds or updates a PingOne connection has been improved to specify that the credential must not be null, empty, or blank.

Adjusted agent token cache TTLs to reflect risk policy evaluation intervals


Corrected an issue with token cache time to lives (TTLs) on agent applications that use the PingOne Protect integration. The agent token cache TTLs no longer prioritize an application's web session Idle Timeout over the Risk Check Interval or Authentication Validity Period defined in the application's risk policy.

Fixed default removal of active session state cookies from requests


Corrected an issue where PingAccess would remove active session state cookies from requests by default. If a component relies on the session state cookie, its absence can cause unexpected behavior, so PingAccess now removes session state cookies conditionally.

Corrected CPU load return message when load is 0


Previously, PingAccess would return a response of N/A when CPU load is unavailable or detected to have a value of zero. PingAccess now provides a response of 0 instead.

Fixed upgrade utility issue when default system encoding isn't UTF-8


Formerly, running the upgrade utility on a system that uses non-UTF character encoding by default could result in the upgrade utility modifying non-ASCII content. This is because there are certain code flows that don’t define a character set to use when transferring data between the source and target version of PingAccess.

The upgrade utility now checks if the character set on the content type header is set to null. If it is, the upgrade utility changes the character set to UTF-8.

Fixed an issue that intermittently slowed API response time


Reconfiguring PingAccess's log context results in an API response time delay. PingAccess is now optimized to prevent log context from reloading during configuration reload unless changes have been made to the enabled log settings API categories or to the underlying categories in the log4j-categories.xml file.

Fixed a potential security vulnerability


Upgraded a component of PingAccess to the latest security standard.

Console Log Settings page doesn't immediately reflect changes made in the API


If you have the administrative console and API open at the same time and you're on a console page that isn't Log Settings, the Log Settings page won't immediately populate any log changes that you make in the API.

To work around this issue, go to the Log Settings page. Perform a hard refresh, or go to another page and then return to Log Settings.