SSL certificates signed by a CA can be used to identify one or both ends of the federation. SSL/TLS provides an encrypted connection between the two parties in which the content of a message is not exposed, thus ensuring confidentiality and message integrity.

SAML SSL and TLS scenarios

SSL/TLS should be used in association with the SOAP responder URL and Single Sign-on Service located at an IdP site. On the SP side, the Artifact Resolution Service should also use SSL/TLS. Optionally, SSL/TLS may also be used to secure communication between internal data stores and PingFederate and between the PingFederate STS and web service client or provider applications.

The SSL/TLS server-client handshake involves negotiating cipher suites to be used for encryption and decryption on each side of a secured transaction. Cipher suites are stored in the following configuration files:

  • com.pingidentity.crypto.SunJCEManager.xml
  • com.pingidentity.crypto.AWSCloudHSMJCEManager.xml
  • com.pingidentity.crypto.LunaJCEManager.xml
  • com.pingidentity.crypto.NcipherJCEManager.xml

These cipher-suite configuration files are located in the <pf_install>/server/default/data/config-store directory. Weaker cipher suites are commented out in these files. Retain this cipher-suite configuration to ensure the most secure transactions.


Due to the import restrictions of some countries, Oracle Server JRE (Java SE Runtime Environment) 8 has built-in restrictions on available cryptographic strength (key size). To use larger key sizes, the Java Cryptography Extension (JCE) "unlimited strength" jurisdiction policy must be enabled. For more information, see the Java 8 release notes from Oracle (

For Oracle Java SE Development Kit 11, the JCE jurisdiction policy defaults to unlimited strength. For more information, see the Oracle JDK Migration Guide (

Starting with PingFederate 9.1, cipher suites are selected based on the order that they are listed in the cipher-suite configuration file for new installations. For upgrades, you may enable the same selection mechanism as well (see Managing cipher suites).


Three methods of authentication, described below, are available for use with PingFederate for browser-based SSO to authenticate connection partners making SOAP requests. For SOAP authentication by STS clients, a separate option using either or both of the first two methods, may be configured (the third method, digital signing, is automatically required). The selection of one or more method(s) must be agreed upon between partners and synchronized within IdP and SP federation implementations:

HTTP Basic authentication
Partners identify themselves by passing username and password credentials.
SSL client certificate authentication

Partners use SSL client certificates presented during SOAP request transactions. Each partner needs to import the other's certificate out-of-band (see Managing SSL client keys and certificates).

Digital signatures
Partners sign the XML message transmitted via the SSL/TLS connection. Signatures are verified by the receiver based upon the certificate(s) configured for that connection. Each partner should import the other's certificate(s) out-of-band (see Managing digital signing certificates and decryption keys).

Trusted certificates

PingFederate validates the trust of all certificates. A certificate is trusted if the certificate of its issuer is in PingFederate's trusted certificate store. The root certificate of the CA, by which a certificate is issued, must be imported into PingFederate's trusted certificate store or contained in the Java runtime cacerts store.