The SAML standards specify that when an SP receives assertions via the POST binding, the SP should keep track of each assertion for the duration of its validity to ensure that it is not replayed (that is, intercepted by a third party and re-posted). For OAuth and OpenID Connect, PingFederate can optionally mandate a unique signed JWT from the client for each request when the client is configured to authenticate via the private_key_jwt client authentication method, to transmit request parameters using in signed request objects, or to do both. PingFederate delegates these responsibilities to the Assertion Replay Prevention Service.
When PingFederate is in clustered mode, the service proxy uses a group RPC-based, preferred-nodes implementation; the configuration file is cluster-assertion-replay-prevention.conf in the <pf_install>/pingfederate/server/default/conf directory.
This service supports both adaptive clustering and directed clustering. For adaptive clustering, PingFederate shares token (assertion or JWT) information with a replica set. If region identifiers are defined, PingFederate shares token information among multiple replica sets across regions. You can optionally override this default behavior in the configuration file for adaptive clustering. For directed clustering, due to the nature of the threat that this service is intended to prevent, you must choose between the sharing all nodes and designating state servers deployment strategies in directed clustering for this service.
The service proxy uses the class:
Unlike other services, the Assertion Replay Prevention Service fulfills only a security
condition, rather than supporting normal SSO functionality. Because many other security
requirements are in place (for example, SSL, no-cache directives, and digital signatures),
there may be situations where the priority placed on cluster performance outweighs the
priority placed on this security check. If you are in this situation, you may wish to
change the implementation for the service point
AssertionReplayPreventionService in the
hivemodule.xml file to one of these classes:
This is the implementation used in standalone mode. It performs all the appropriate replay checks but does not share any data with other nodes. A replay attempt routed to the same server node would fail, but other nodes would not have sufficient information to stop the transaction.
This implementation disables assertion-replay prevention; however, you may wish to use it, with caution, when performance is an absolute priority.