Added support for policy deployment from
Microsoft Azure blob storage
Enabled configuration of the SpEL allowed list
in PDP mode
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
Expanded Policy Editor database
support to include PostgreSQL
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
Added support for the MuleSoft API Gateway in a
sideband architecture
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.
OpenID Connect (OIDC) Authorization Code with
Proof Key for Code Exchange (PKCE)
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.
Upgrading from early access to general
availability
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'".
Server profiles replace peer
setup
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.
Upgrading from earlier versions of PingAuthorize
Added support for password storage
schemes
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 redaction capability for
dsconfig
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.
Mirrored configuration change
logging
Updated the server to record the original requester DN and IP
address in access log and configuration audit log messages for mirrored
configuration changes.
Added support for obtaining secrets from
CyberArk Conjur
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.
Added support for obtaining secrets from
Azure Key Vault
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
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.
Runtime server problem-status handling
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.
Added administrative console PIN
support
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.
Administrative console file retrieval with
SSO
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.
Added file servlet support for OIDC and
OAuth 2.0
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.
manage-profile
generate-profile argument validation
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.
Expanded ldap-diff
capabilities
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.
Added TLS protocol configuration to the
crypto manager
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 certificate management support
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.
Secret key loss when
removing a server from the topology
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.
Note:
Since this change only applies to the most recent version of
remove-defunct-server and dsreplication
disable, if you are removing a server from a multi-version
topology, you should run that tool from the most recent version. In the
past dsreplication disable and
remove-defunct-server could only be run from an
older version, but now in the case of removing a server from the
topology, they should be run from the most recent version in the
topology. If you run the tool from an older server, it will not include
this fix, and you may lose access to secret keys from servers that are
removed from the topology.
Shutting down PingAuthorize Server with an invalid package
store
An invalid deployment package store no longer prevents the
PingAuthorize Server from shutting
down.
remove-defunct-server attribute removal
Fixed an issue in which remove-defunct-server
would remove attributes from config.ldif if they were
identical apart from case.
Policy Editor batch
scripts refer to non-existent Java files
The PingAuthorize
Policy Editor
start-server.bat and stop-server.bat
scripts no longer output messages referring to non-existent
java.properties or
dsjavaproperties.
JVM segmentation faults
during start-server
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.
Configuration keys and
values in the Policy Editor Test Suite
OIDC authentication to
the Policy Editor for PingOne users with TLS 1.3 might limit
functionality
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.
Deployment package
store detection
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.
Can't use an existing
persistent database with Docker volumes
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.
Can't persist the
database in /opt/db with Docker volumes
Reconfiguring the
Policy Editor in a Docker volume
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.
- 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.
- You decide to change the configuration, so you edit the
custom-options.yml file.
- 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"
- 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 from earlier versions
Upgrading multi-server topologies that contain PingDataGovernance
6.x or 7.x to PingAuthorize is not
supported.
Using the Periodic
Stats Logger
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.
Policy Editor snapshot import error
The Policy Editor produces an error when a user
attempts to import an exported snapshot that contains references to named value
processors.
Using the
administrative console with Tomcat 9.0.31
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.
Harmless failure
message when stopping ping-authorize.service
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.