Page History

...

WS-Security supports many ways of specifying tokens. One of these is the UsernameToken header. It is a standard way to communicate a username and password or password digest to another endpoint. Be sure to review the OASIS UsernameToken Profile Specification for important security considerations when using UsernameTokens. Note that the nonce support necessary for guarding

If a nonce is present in a UsernameToken then it should be cached by the message recipient to guard against replay attacks. This behaviour is active enabled by default starting with CXF 2.6.0 but unavailable in versions prior to that. This functionality is also available from Apache CXF 2.4.7 and 2.5.3 onwards, but is not enabled by default at all for backwards-compatibility reasons. The following properties control nonce caching:

• "ws-security.enable.nonce.cache" - The default value (for CXF 2.6.0) is "true" for message recipients, and "false" for message initiators. Set it to true to cache for both cases. The default value for CXF 2.4.x and 2.5.x is false.
• "ws-security.nonce.cache.instance" - This holds a reference to a ReplayCache instance used to cache UsernameToken nonces. The default instance that is used is the EHCacheReplayCache, which uses Ehcache to cache the nonce values.
• "ws-security.cache.config.file" - Set this property to point to a configuration file for the underlying caching implementation. By default the cxf-ehcache.xml file in the CXF rt-ws-security module is used.

For the server side, you'll want to set up the following properties on your WSS4JInInterceptor (see above for code sample):

...