Secure sockets layer
A certificate authority (CA)-signed SSL certificate identifies one or both ends of the federation. SSL/TLS provides an encrypted connection between the two parties to avoid exposing the content of a message. This promotes 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 identity provider (IdP) site. On the service provider (SP) side, the Artifact Resolution Service should also use SSL/TLS. Optionally, SSL/TLS can also be used to secure communication between internal data stores and PingFederate and between the PingFederate security token service (STS) and web service client or provider applications.
The SSL/TLS server-client handshake involves negotiating cipher suites to use for encryption and decryption on each side of a secured transaction. You can find cipher suites 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
-
com.pingidentity.crypto.BCFIPSJCEManager.xml
These cipher-suite configuration files are located in the <pf_install>/server/default/data/config-store
directory. These files comment out weaker cipher suites. To ensure the most secure transactions, retain this cipher-suite configuration.
Because of the import restrictions of some countries, Oracle Server Java SE Runtime Environment (JRE) 8 has built-in restrictions on available cryptographic strength (key size). To use larger key sizes, enable the Java Cryptography Extension (JCE) unlimited strength jurisdiction policy. For more information, see the Java 8 release notes in Oracle’s documentation. For Oracle Java SE Development Kit 11, the JCE jurisdiction policy defaults to unlimited strength. For more information, see the Oracle JDK Migration Guide in Oracle’s documentation. |
Starting with version 9.1, PingFederate selects cipher suites based on the order that they appear in the cipher-suite configuration file for new installations. For upgrades, enable the same selection mechanism. For more information, see Managing cipher suites.
Authentication
PingFederate browser-based single sign-on (SSO) uses three methods to authenticate connection partners making SOAP requests. For STS client SOAP authentication, configure a separate option using either or both of the first two methods listed here. Partners must agree upon the selection of methods and synchronize 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 partner’s certificate out-of-band For more information, see Manage SSL client keys and certificates.
- Digital signatures
-
Partners sign the XML message transmitted through the SSL/TLS connection. The receiver verifies the signatures based upon the certificates configured for that connection. Each partner should import the others' certificates out-of-band. For more information, see Manage digital signing certificates and decryption keys.
Trusted certificates
PingFederate validates the trust of all certificates. PingFederate trusts certificates if the issuer’s certificate is also in PingFederate’s trusted certificate store. You must import the root certificate of the CA into PingFederate’s trusted certificate store or into the Java runtime cacerts
store.