- 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
- 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 may 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. Note:
Although strongly discouraged, this policy change may 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. Note:
Although strongly discouraged, this policy change may 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.
- 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.
- 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 such connections to use the newer algorithm RSA-OAEP (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 (or a more recent version), 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 screen 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.
Page created: 12 Sep 2019 |
Page updated: 18 Mar 2020