PingFederate Server

Upgrade considerations introduced in PingFederate 6.x

Cluster bind address required

Starting with PingFederate 6.11, the pf.cluster.bind.address property located in <pf_install>/pingfederate/bin/run.properties is required when running PingFederate in a cluster. The default value is NON_LOOPBACK.

Decryption and digital signing policy changes

Potential security vulnerabilities have resulted in the following changes to PingFederate as of version 6.11. In some cases, these might impact interoperability with partners:

  • When acting as an SP and using the POST binding, PingFederate decrypts an assertion only when the SAML response has been signed. An unsigned SAML response that contains an encrypted assertion is rejected.

    Although strongly discouraged, this policy change can be reverted on a per-connection basis via the EntityIdsToAllowAssertionDecryptionWithoutResponseSignature list located in the <pf_install>/pingfederate/server/default/data/config-store/org.sourceid.saml20.profiles.sp.HandleAuthnResponse.xml file.

  • When acting as an IdP, PingFederate always signs a SAML response (even when the assertion is also signed) if it contains an encrypted assertion.

    Although strongly discouraged, this policy change can be reverted on a per-connection basis via the EntityIdsToOmitResponseSignatureOnSignedEncryptedAssertion list located in the <pf_install>/pingfederate/server/default/data/config-store/org.sourceid.saml20.profiles.idp.HandleAuthnRequest.xml file.

  • When acting as an IdP, PingFederate decrypts an encrypted NameID in an Attribute Query only when the request has been signed or the client has authenticated with basic or mutual TLS.

Key transport algorithm deprecated

Due to security risks associated with the RSA-v1.5 algorithm used for key transport, it is no longer available for new connections starting with PingFederate 6.11. Existing connections in which this algorithm is configured continue to support it. However, we recommend upgrading to use the newer RSA-OAEP algorithm. See Selecting an encryption certificate for SP connections and Choosing an encryption certificate (SAML 2.0) for IdP connections.

OAuth persistent grants expiration

When upgrading to PingFederate 6.8 later, all persistent grants for any existing OAuth deployments using an Oracle MySQL database will expire. To address this issue, the expires column in the pingfederate_access_grant table should be set to null prior to the upgrade. If necessary, contact Ping Identity support for assistance.

OAuth clients reconfiguration

Neither the Upgrade Utility nor the platform-specific installers migrates OAuth clients that are created from PingFederate 6.5 through 7.0. Use any of the following interfaces to reconfigure your OAuth clients:

  • The Clients window (Applications → OAuth → Clients) in the PingFederate administrative console.

  • The /oauth/clients administrative API endpoint.

  • The REST-based web service for OAuth client management at the /pf-ws/rest/oauth/clients and /pf-ws/rest/oauth/clients/id endpoints. This web service requires the client records to be stored in a database.

    Note that PingFederate has been storing OAuth clients in XML files since version 7.1; these clients are migrated to the new installation. In addition, if you have configured PingFederate 6.8 (or a more recent version) to store OAuth clients in an external database, the new installation retains that configuration as well.

OGNL library upgraded

The OGNL library has been upgraded in version 6.4. If you use OGNL expressions in versions prior to 6.4, we recommend retesting the expressions using the PingFederate administrative console or runtime tests.