PingAuthorize 9.0 (December 2021) - PingAuthorize - 9.0

The PingAuthorize Server can now consume deployment packages published to Microsoft Azure blob storage. This enables policy writers to deploy new policies to a central Azure deployment package store read by the PingAuthorize Server running in embedded mode. For more information, see Adding an Azure deployment package store, Configuring the Policy Editor to publish policies to a deployment package store, and Using the Deployment Manager .

Now you can configure the SpEL allowed list when the Policy Decision Service is running in embedded policy decision point (PDP) mode. An out-of-the-box PingAuthorize installation adds the following classes to the default allowed list: String, Date, Random, UUID, Integer, Long, Double, Byte, Math, Boolean, LocalDate, DayOfWeek, Instant, ChronoUnit, SimpleDateFormat. When configuring a policy deployment package containing SpEL expressions that reference additional Java classes, administrators must use dsconfig or the administrative console to add spel-allowlisted-class attributes to the Policy Decision Service. The class must also be available on the server classpath at server start. For non-standard Java classes, place the .jar file in the server lib folder

The PingAuthorize Policy Editor can now persist its policies, trust framework, and versioning data in a PostgreSQL policy database instead of the default H2 file-based database. To initialize the database, use the instructions at https://github.com/pingidentity/pingauthorize-contrib/tree/main/sql/postgresql. To configure the Policy Editor for PostgreSQL, use the following setup options:

• --dbConnectionString The JDBC connection string (for example, 'jdbc:postgresql://localhost:5432/policy_db')
• --dbAppUsername The PostgreSQL user
• --dbAppPassword The user's password

Now you can deploy PingAuthorize in a sideband configuration with the MuleSoft API Gateway. With a sideband deployment, your organization can quickly set up an environment for fine-grained, dynamic authorization that integrates with existing identity management infrastructure and requires minimal changes to your network configuration. For more information about our custom MuleSoft policy, see MuleSoft API gateway integration.

Policy Editor setup in OpenID Connect (OIDC) authentication mode now uses the Authorization Code with Proof Key for Code Exchange (PKCE) grant type by default, instead of the implicit grant type. For information about configuring the Policy Editor in OIDC authentication mode, see Installing the PingAuthorize Policy Editor noninteractively.

If you are upgrading from PingAuthorize 9.0.0.0 Early Access to 9.0.0.0 General Availability, you must upgrade both the PingAuthorize Server and the Policy Editor before you use the Policy Decision Service in external mode. Upgrading only one component results in this error: "Please upgrade to PingAuthorize Policy Editor version '9.0.0.0'".

Peer server setup and clustered configuration have been removed from setup. To manage server configuration, use server profiles instead of peer setup. Server profiles support deployment best practices such as automation and Infrastructure-as-Code (IaC). For more information about server profiles, see Deployment automation and server profiles.

For more considerations, see Upgrade considerations.

Added support for password storage schemes that allow users to authenticate with passwords stored in the Amazon AWS Secrets Manager service, the Microsoft Azure Key Vault service, a CyberArk Conjur instance, or a HashiCorp Vault instance.

Added a global configuration property that can be used to indicate that the values of sensitive configuration properties should be redacted when constructing the dsconfig representation for a configuration change, as may be included in the server's configuration audit log or administrative alerts whenever a configuration change is applied. By default, the values of configuration properties that are defined as sensitive will be obscured rather than redacted, which allows the change to be replayed without revealing the actual value of the property. However, it is now possible to redact such values rather than obscuring them, which provides stronger protection against exposing those values, but may interfere with the ability to replay the configuration audit log if it contains changes involving sensitive properties.

Updated the server to record the original requester DN and IP address in access log and configuration audit log messages for mirrored configuration changes.

The Conjur cipher stream provider can use a retrieved secret to generate the encryption key used to protect the contents of the encryption settings database. The Conjur passphrase provider can be used in other cases in which the server might need a clear-text secret, including as a PIN needed to access a certificate key store or as credentials for authenticating to an external service. The server may authenticate to Conjur using a username and a password or an API key.

The Azure Key Vault cipher stream provider can use a retrieved secret to generate the encryption key used to protect the contents of the encryption settings database. The Azure Key Vault passphrase provider can be used in other cases in which the server might need a clear-text secret, including as a PIN needed to access a certificate key store or as credentials for authenticating to an external service.

Added a PKCS #11 cipher stream provider that can require access to a certificate in a PKCS #11 token to unlock the server's encryption settings database. Only certificates with RSA key pairs may be used because JVMs do not currently provide adequate key wrapping support for elliptic curve key pairs.

When the Policy Decision Service is unable to handle requests due to misconfiguration or problems with the runtime environment, the PingAuthorize Server status is now DEGRADED instead of UNAVAILABLE. Orchestration systems like Kubernetes now remove such servers from pools instead of restarting them, allowing server administrators to investigate and correct the issue.

The administrative console can now be configured to supply PINs to its trust stores through the oidc-trust-store-pin-passphrase-provider and trust-store-pin-passphrase-provider settings. This means trust store types that require passphrases (for example, PKCS12 or BCFKS) are now properly supported.

The administrative console can now retrieve files created from collect-support-data or server-profile tasks when using single sign-on (SSO) to authenticate with the managed server.

Updated the file servlet to add support for token-based authentication using an OAuth 2.0 access token or an OpenID Connect ID token. The servlet previously only supported basic authentication.

Improved includePath argument validation performed by the manage-profile generate-profile tool. The tool will only use relative paths that exist below the server root, and it previously silently ignored absolute paths or relative paths that referenced files outside of the server root. It will now exit with an error if the includePath argument is used to provide an absolute path or a path outside the server root. It will accept but warn about paths that reference files that do not exist.

Made several improvements to the ldap-diff tool:

• Added the ability to perform a byte-for-byte comparison of attribute values rather than using schema-based logical equivalence.
• Added the ability to use a properties file to obtain default values for command-line arguments.
• Improved the ability to use different TLS-related settings for the source and target servers.
• Improved support for SASL authentication.

Updated the crypto manager configuration to add properties for controlling the set of TLS protocols and cipher suites that will be used for outbound connections, as well as properties for controlling whether to enable TLS cipher suites that rely on the SHA-1 digest algorithm or the RSA key exchange algorithm.

Added support for the use of JDKs obtained through Eclipse Foundation and BellSoft.

Added support for new extended operations that can be used to help manage the server's listener and inter-server certificates. Updated the replace-certificate tool to add support for replacing and purging certificates in a remote instance, and to allow skipping validation for the new certificate chain.

Fixed an issue introduced in version 7.0.0.0 where secret keys under cn=Topology,cn=config could be lost when removing a server from the topology. When a server is removed via the dsreplication disable or remove-defunct-server tools, its secret keys will now be distributed among the remaining members of the topology. The keys from the rest of the topology will also be copied to the server being removed.

The cipher secret keys in the topology that are affected by this change are used by reversible password storage schemes (except for AES256, which uses the encryption settings database). If you are using a reversible password storage scheme other than AES256, prior to this fix, you could lose access to keys that had been used for reversible password encryption when removing servers from the topology.

An invalid deployment package store no longer prevents the PingAuthorize Server from shutting down.

Fixed an issue in which remove-defunct-server would remove attributes from config.ldif if they were identical apart from case.

The PingAuthorize Policy Editor start-server.bat and stop-server.bat scripts no longer output messages referring to non-existent java.properties or dsjavaproperties.

Removed -XX:RefDiscoveryPolicy=1 from the default start-server Java arguments. In rare cases, this argument was related to segmentation faults in the Java virtual machine, especially when used with the G1 garbage collector.

The Policy Editor now uses policy configuration keys and values correctly in Test Suite tests. For details about configuring policy configuration keys, see Environment-specific Trust Framework attributes.

When PingOne users authenticate with OIDC to the Policy Editor, environments using OpenJDK versions older than 11.0.3 might run into an intermittent TLS 1.3 issue preventing them from loading test scenarios. The issue appears in the logs as com.symphonicsoft.authentication.OidcAuthenticator: Could not retrieve jwks information from '<ping-one-url>/as/jwks' and includes the following message: javax.net.ssl.SSLException: No PSK available. Unable to resume. This is an OpenJDK bug that has been fixed in version 11.0.3. To circumvent this issue, you can upgrade to OpenJDK 11.0.3 or newer. Disabling TLS 1.3 also prevents this issue.

If the configured deployment package store is not available when the PingAuthorize Server starts, it will not be able to detect when the store becomes available again. To ensure that the PingAuthorize Server begins using the deployment package store when the store is available again, you must restart the server or change the Policy Decision Service configuration.

The pingdatagovernancepap and pingauthorizepap Docker images now run as unprivileged (non-root) users by default. If you have existing pingdatagovernancepap policy databases, configure the containers to run as root. For more information, see Installing PingAuthorize Policy Editor using Docker.

To persist a policy database in a Docker volume, create a new Docker volume with a mount target of /opt/out instead of /opt/db. For more information, see Installing PingAuthorize Policy Editor using Docker.

When you are using the Policy Editor in a Docker volume, changing the configuration using an options.yml file also requires that you create an empty file /opt/out/instance/delete-after-setup before you restart pingauthorizepap. Consider the following example.

1. You start the container with a command like the one below.
   Note:

   The following command bind mounts a customized options.yml file named custom-options.yml to the server root using the server profile capability. The host system server-profile folder must contain instance/custom-options.yml for this example to work correctly. See https://devops.pingidentity.com/reference/config/.

   $ docker run --network=<network_name> --name pap -p 8443:1443 \
    --env-file ~/.pingidentity/config \
    --volume /home/developer/pap/server-profile:/opt/in/ \
    --env PING_OPTIONS_FILE=custom-options.yml \
    --volume /home/developer/pap/Symphonic.mv.db:/opt/out/Symphonic.mv.db \
    --env PING_H2_FILE=/opt/out/Symphonic \
    pingidentity/pingauthorizepap:<TAG>

   where the Docker image <TAG> is only a placeholder.
2. You decide to change the configuration, so you edit the custom-options.yml file.
3. You create the empty file with a command like this one.

   docker exec -it pap /bin/sh -c "touch /opt/out/instance/delete-after-setup"

4. With that file in place, you can now restart the Policy Editor with the following commands.

   $ docker stop pap
   $ docker start --attach pap

Upgrading multi-server topologies that contain PingDataGovernance 6.x or 7.x to PingAuthorize is not supported.

Published throughput and latency stats for SCIM, Sideband, and Gateway requests for the Periodic Stats Logger are not recorded until the requests are made and the logger is reset.

The Policy Editor produces an error when a user attempts to import an exported snapshot that contains references to named value processors.

Several known issues can occur when you use the administrative console with Tomcat 9.0.31. You can resolve these issues by upgrading to Tomcat 9.0.33 or later.

If you use the create-systemd-script tool to create a forking systemd service, the service is stopped by the systemctl stop ping-authorize.service command. At that time, you can see the status using the systemctl status ping-authorize.service command. That status might contain an indication of failure: Active: failed (Result: exit-code). This error has to do with the way the service exits. It is harmless.