PingAccess 7.3 (June 2023) - PingAccess - 7.3

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 9.0 running on RHEL 8 or 9 to the PingAccess agent for Apache (RHEL). For more information, see:

• RHEL agent system requirements
• Installing on an IBM HTTP Server using Apache 2.4

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:

• For more information on how to establish a connection between PingOne Protect and PingAccess, see PingOne connections.
• For more information on how to create a risk policy, see Risk policies.
• For more information on how to assign a risk policy to a specific application or application resource, see the Application Type table entry in Application field descriptions or step 11 of Adding application resources.

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.

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.

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.

• For more information on applying PingAuthorize rules to inbound web requests, see Adding PingAuthorize access control rules.
• For more information on applying PingAuthorize rules to outbound web responses, see Adding PingAuthorize response filtering rules.
• For more information on how to add rules to applications or specific application resources, see Applying rules to applications and resources.

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.

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.
  Note:

  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.

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.

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.

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

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.

For more information, see Upgrade considerations.

Added a new cluster configuration setting to the run.properties 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.

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.

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.

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 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 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.

A setting in the upgrade utility and PingAccess Service/conf directory, Djava.security.egd=file:/dev/./urandom, was slowing request processing. This setting is specific to Unix environments, so it was removed from Windows script/conf files in PingAccess.

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.

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.

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.

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.

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.

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.

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.

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.

Upgraded a component of PingAccess to the latest security standard.

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.