cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r833904 - in /websites/production/cxf/content: cache/docs.pageCache docs/ws-security.html
Date Wed, 03 Oct 2012 15:47:26 GMT
Author: buildbot
Date: Wed Oct  3 15:47:26 2012
New Revision: 833904

Production update by buildbot for cxf


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">&lt;jaxws:inInterceptors&gt;</span>
+    <span class="code-tag">&lt;bean class=<span class="code-quote">""</span>&gt;</span>
+        <span class="code-tag">&lt;constructor-arg&gt;</span>
+            <span class="code-tag">&lt;map&gt;</span>
+                <span class="code-tag">&lt;entry key=<span class="code-quote">"action"</span>
value=<span class="code-quote">"Signature Timestamp"</span>/&gt;</span>
+                <span class="code-tag">&lt;entry key=<span class="code-quote">"signaturePropFile"</span>
value=<span class="code-quote">"..."</span>/&gt;</span>
+                <span class="code-tag">&lt;entry key=<span class="code-quote">"passwordCallbackClass"</span>value=<span
+           <span class="code-tag">&lt;/map&gt;</span>
+        <span class="code-tag">&lt;/constructor-arg&gt;</span>
+    <span class="code-tag">&lt;/bean&gt;</span>
+    <span class="code-tag">&lt;bean class=<span class="code-quote">""</span>/&gt;</span>
+<span class="code-tag">&lt;/jaxws:inInterceptors&gt;</span>
 <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,, 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>

View raw message