In previous releases of WebSphere® Application Server, the
nonce was cached locally. WebSphere Application Server Versions 6 and later
use distributed nonce caching. The distributed nonce cache makes it possible
to replicate nonce data among servers in a WebSphere Application Server cluster.
If nonce elements are in a SOAP header, all nonce values are cached by
the server in the cluster. If the distributed nonce cache is enabled, the
cached nonce values are copied to other servers in the same cluster. Then,
if the message with the same nonce value is sent to (one of) other servers,
the message is rejected. A received nonce cache value is cached and replicated
in a push manner among other servers in the cluster with the same replication
domain. The replication is an out-of-process call and, in some cases, is a
remote call. Therefore, there is latency when the content of the cache in
the cluster is updated.
For example, you might have application server A and application server
B in cluster C.
- A SOAP client sends a message with nonce abc to application server
A.
- The server caches the value and pushes it to the other application server
B.
- If the client sends the message with nonce abc to application
server B after a certain time frame, the message is rejected and if the application
server B receives the nonce with the same value within a specified period
of time, a SoapSecurityException is thrown by application server B.
For
more information, see the information that explains nonce cache timeout, nonce
maximum age, and nonce clock skew in Token generator configuration settings.
- If the client sends the message with another nonce value of xyz,
the message is accepted, the value is cached by application server B and is
copied into the other application servers within the same cluster.
Important: The
distributed nonce caching feature uses the WebSphere Application Server data
replication service (DRS). The data in the local cache is pushed to the cache
in other servers in the same replication domain. The replication is an out-of-process
call and, in some cases, is a remote call. Therefore, there is a possible
delay in replication while the content of the cache in each application server
within the cluster is updated. The delay might be due to network traffic,
network workload, machine workload, and so on.