svn commit: r817210 - in /websites/production/cxf/content: cache/docs.pageCache docs/ws-security.html

[bu...@apache.org]

Author: buildbot
Date: Fri May 11 09:48:28 2012
New Revision: 817210

Log:
Production update by buildbot for cxf

Modified:
    websites/production/cxf/content/cache/docs.pageCache
    websites/production/cxf/content/docs/ws-security.html

Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/cxf/content/docs/ws-security.html
==============================================================================
--- websites/production/cxf/content/docs/ws-security.html (original)
+++ websites/production/cxf/content/docs/ws-security.html Fri May 11 09:48:28 2012
@@ -374,7 +374,12 @@ CryptoCoverageChecker checker = <span cl
 
 <h2><a shape="rect" name="WS-Security-UsernameTokenAuthentication"></a>Username Token Authentication</h2>
 
-<p>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 <a shape="rect" class="external-link" href="http://tinyurl.com/65n78j" rel="nofollow">UsernameToken Profile Specification</a> for important security considerations when using UsernameTokens.  Note that the nonce support necessary for guarding against replay attacks is active by default starting with CXF 2.6.0 but unavailable in versions prior to that.</p>
+<p>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 <a shape="rect" class="external-link" href="http://tinyurl.com/65n78j" rel="nofollow">UsernameToken Profile Specification</a> for important security considerations when using UsernameTokens. </p>
+
+<p>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 enabled by default starting with CXF 2.6.0. 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:</p>
+
+<ul><li>"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.</li><li>"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.</li><li>"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.</li></ul>
+
 
 <p>For the server side, you'll want to set up the following properties on your WSS4JInInterceptor (see <a shape="rect" href="#WS-Security-addinterceptors">above</a> for code sample):</p>
 <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">