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.