---
title: Assertion Replay Prevention Service
description: The Assertion Replay Prevention Service tracks POST assertions to prevent replay.
component: pingfederate
version: 13.1
page_id: pingfederate:server_clustering_guide:pf_assertion_replay_prevention_service
canonical_url: https://docs.pingidentity.com/pingfederate/13.1/server_clustering_guide/pf_assertion_replay_prevention_service.html
llms_txt: https://docs.pingidentity.com/pingfederate/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
revdate: March 17, 2026
section_ids:
  related-links: Related links
---

# Assertion Replay Prevention Service

The Assertion Replay Prevention Service tracks POST assertions to prevent replay.

SAML standards specify that when a service provider (SP) *(tooltip: \<div class="paragraph">
\<p>In SAML, an entity that receives and accepts an authentication assertion issued by an IdP, typically for the purpose of allowing access to a protected resource.\</p>
\</div>)* receives assertions from 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 mandate a unique signed JSON Web Token (JWT) *(tooltip: \<div class="paragraph">
\<p>An IETF standard container format for a JSON object used for the secure exchange of content, such as identity or entitlement information. You can find the industry standard in \<a href="https\://datatracker.ietf.org/doc/html/rfc7519">RFC 7519\</a>.\</p>
\</div>)* from the client for each request when the client is configured to authenticate with the private\_key\_jwt or client\_secret\_jwt client authentication method. 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 `<pf_install>/pingfederate/server/default/conf/cluster-assertion-replay-prevention.conf`.

The Assertion Replay Prevention 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, 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 `org.sourceid.saml20.service.impl.grouprpc.AssertionReplayPreventionServiceGroupRpcImpl`.

Unlike other services, the Assertion Replay Prevention Service fulfills only a security condition, rather than supporting normal SSO functionality, because there might be situations where the priority placed on cluster performance outweighs the priority placed on this security check. If you are in this situation, you have the option to change the implementation for the service point `AssertionReplayPreventionService` in the `<pf_install>/pingfederate/server/default/conf/service-points.conf` file to one of these classes:

* `org.sourceid.saml20.service.impl.localmemory.AssertionReplayPreventionSvcInMemoryImpl`

  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.

* `org.sourceid.saml20.service.impl.localmemory.AssertionReplayPreventionServiceNullImpl`

  This implementation disables assertion-replay prevention. Use with caution when performance is an absolute priority.

## Related links

* [Adaptive clustering](pf_adaptiv_cluster.html)

* [Directed clustering](pf_directed_cluster.html)
