You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by bu...@apache.org on 2012/10/03 17:47:26 UTC
svn commit: r833904 - in /websites/production/cxf/content:
cache/docs.pageCache docs/ws-security.html
Author: buildbot
Date: Wed Oct 3 15:47:26 2012
New Revision: 833904
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 Wed Oct 3 15:47:26 2012
@@ -312,6 +312,27 @@ CryptoCoverageChecker checker = <span cl
<p>After configuring the interceptor as above, simply add the interceptor to your client or server interceptor chain as shown previsouly with the WSS4J interceptors. Ensure that you include the WSS4JInInterceptor in the chain or all requests will be denied if you enforce any coverage XPaths.</p>
+<p>The CryptoCoverageChecker is somewhat complex to set up for the most common use-cases for signature verification and decryption, as it involves adding XPath expressions and the corresponding prefix/namespace pairs. In Apache CXF 2.4.9, 2.5.5 and 2.6.2, a new subclass of CryptoCoverageChecker has been introduced. The DefaultCryptoCoverageChecker provides an easy way to ensure that the SOAP Body is signed or encrypted, that the Timestamp is signed, and that the WS-Addressing ReplyTo and FaultTo headers are signed (if they are present in the message payload).</p>
+
+<p>The default configuation is that the SOAP Body, (WSU) Timestamp and WS-Addressing ReplyTo and FaultTo headers must be signed (if they exist in the message payload). This provides an out-of-the-box way of preventing XML Signature wrapping attacks. All that is required is that the DefaultCryptoCoverageChecker be added to the in-interceptor chain. For example:</p>
+
+<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
+<pre class="code-xml">
+<span class="code-tag"><jaxws:inInterceptors></span>
+ <span class="code-tag"><bean class=<span class="code-quote">"org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"</span>></span>
+ <span class="code-tag"><constructor-arg></span>
+ <span class="code-tag"><map></span>
+ <span class="code-tag"><entry key=<span class="code-quote">"action"</span> value=<span class="code-quote">"Signature Timestamp"</span>/></span>
+ <span class="code-tag"><entry key=<span class="code-quote">"signaturePropFile"</span> value=<span class="code-quote">"..."</span>/></span>
+ <span class="code-tag"><entry key=<span class="code-quote">"passwordCallbackClass"</span>value=<span class="code-quote">"..."</span>/></span>
+ <span class="code-tag"></map></span>
+ <span class="code-tag"></constructor-arg></span>
+ <span class="code-tag"></bean></span>
+ <span class="code-tag"><bean class=<span class="code-quote">"org.apache.cxf.ws.security.wss4j.DefaultCryptoCoverageChecker"</span>/></span>
+<span class="code-tag"></jaxws:inInterceptors></span>
+</pre>
+</div></div>
+
<h3><a shape="rect" name="WS-Security-CustomProcessors"></a>Custom Processors</h3>
<p>As of CXF 2.0.10 and 2.1.4, you can specify custom WSS4J Processor configurations on the WSS4JInInterceptor. To activate this configuration option, one provides a non-WSS4J defined property, wss4j.processor.map, to the WSS4JInInterceptor as shown in the following Spring example. The same configuratoin can be acheieved through the API as well. The key value is an XML qualified name of the WS-S header element to process with the given processor implementation. The entry values can be a String representing a class name of the processor to instantiate, an Object implementing Processor, or null to disable processing of the given WS-S header element.</p>