When using a hardware security module (HSM), some restrictions apply to PingFederate.
- PingFederate does not store public certificates on the hardware module for signature verification, encryption, and back-channel authentication. Instead, the local trust store on the file system stores these certificates.
- As an OpenID Provider, PingFederate can use static or dynamically-rotating keys to sign ID tokens, JSON web tokens (JWTs) for client authentication, and OpenID Connect request objects. When using dynamically-rotating keys as part of the default configuration, the memory, not the HSM, stores short-term keys. The HSM can store static keys.
- Private keys are not exportable. When configured for use with the HSM, PingFederate disables administrative-console options for this feature. Only the public portion of generated keys is exportable.
- When running in FIPS 140-2 level 3 compliance, also called strict FIPS mode, private keys cannot be imported. In this mode, administrative-console options for this feature are disabled.
- When using the Configuration Archive feature, any keys,
certificates, or objects generated and stored on the HSM prior to saving a configuration
archive must continue to exist unaltered when the archive is restored. In other words, the
PingFederate user interface must execute any deletion or creation of
objects on the HSM for proper operation.
For example, you create and save objects A, B, and C to the HSM and create a data archive that contains references to those objects. If you delete object C and attempt to recover it through the data archive, PingFederate fails. Because the data archive contains a reference to the object and the object has been deleted from the HSM, you cannot use that data archive again.
- PingFederate limits cipher suites to those listed in the <pf_install>/pingfederate/server/default/data/config-store/com.pingidentity.crypto.LunaJCEManager.xml file.