Author: buildbot
Date: Tue Sep 23 12:47:47 2014
New Revision: 923234
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 Tue Sep 23 12:47:47
2014
@@ -117,52 +117,15 @@ Apache CXF -- WS-Security
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><h1 id="WS-Security-WS-Security">WS-Security</h1>
-
-<p>WS-Security provides means to secure your services above and beyond
transport level protocols such as HTTPS. Through a number of standards such as
XML-Encryption, and headers defined in the WS-Security standard, it allows you
to:</p>
-<ul><li>Pass authentication tokens between services</li><li>Encrypt messages
or parts of messages</li><li>Sign messages</li><li>Timestamp
messages</li><li>Manage public keys using <a shape="rect"
href="http://cxf.apache.org/docs/xml-key-management-service-xkms.html";>XKMS</a></li></ul>
-
-
-<p>CXF relies on <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j";>WSS4J</a> in large part to implement
WS-Security. Within your own services, WS-Security can be activated by using
<a shape="rect"
href="http://cxf.apache.org/docs/ws-securitypolicy.html";>WS-SecurityPolicy</a>,
which provides a comprehensive and sophisticated validation of the security
properties of a received message. A non-WS-SecurityPolicy approach is usually
also possible by way of CXF interceptors added to your service and/or client as
detailed in this article.</p>
-
-<h1 id="WS-Security-Overviewofencryptionandsigning">Overview of encryption and
signing</h1>
-
-<p>WS-Security makes heavy use of public/private key cryptography. To really
understand how to configure WS-Security, it is helpful - if not necessary - to
understand these basics. The Wikipedia has an <a shape="rect"
class="external-link"
href="http://en.wikipedia.org/wiki/Public-key_cryptography";
rel="nofollow">excellent entry</a> on this, but we'll try to summarize the
relevant basics here (This content is a modified version of the wikipedia
content..)</p>
-
-<p>With public key cryptography, a user has a pair of public and private keys.
These are generated using a large prime number and a key function.<br
clear="none">
-<img class="confluence-embedded-image confluence-external-resource"
src="http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Public_key_making.svg/250px-Public_key_making.svg.png";
data-image-src="http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Public_key_making.svg/250px-Public_key_making.svg.png";></p>
-
-<p>The keys are related mathematically, but cannot be derived from one
another. With these keys we can encrypt messages. For example, if Bob wants to
send a message to Alice, he can encrypt a message using her public key. Alice
can then decrypt this message using her private key. Only Alice can decrypt
this message as she is the only one with the private key.<br clear="none">
-<img class="confluence-embedded-image confluence-external-resource"
src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f9/Public_key_encryption.svg/280px-Public_key_encryption.svg.png";
data-image-src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f9/Public_key_encryption.svg/280px-Public_key_encryption.svg.png";></p>
-
-<p>Messages can also be signed. This allows you to ensure the authenticity of
the message. If Alice wants to send a message to Bob, and Bob wants to be sure
that it is from Alice, Alice can sign the message using her private key. Bob
can then verify that the message is from Alice by using her public key.<br
clear="none">
-<img class="confluence-embedded-image confluence-external-resource"
src="http://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/Public_key_signing.svg/280px-Public_key_signing.svg.png";
data-image-src="http://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/Public_key_signing.svg/280px-Public_key_signing.svg.png";></p>
-
-<h1 id="WS-Security-ConfiguringtheWSS4JInterceptors">Configuring the WSS4J
Interceptors</h1>
-
-<p>To enable WS-Security within CXF for a server or a client, you'll need to
set up the WSS4J interceptors. You can either do this via the API for
standalone web services or via Spring XML configuration for servlet-hosted
ones. This section will provide an overview of how to do this, and the
following sections will go into more detail about configuring the interceptors
for specific security actions.</p>
-
-<p>It is important to note that:</p>
-<ol><li>If you are using CXF 2.0.x, you must add the SAAJ(In/Out)Interceptors
if you're using WS-Security (This is done automatically for you from CXF 2.1
onwards). These enable creation of a DOM tree for each request/response. The
support libraries for WS-Security require DOM trees.</li><li>The web service
provider may not need both in and out WS-Security interceptors. For instance,
if you are just requiring signatures on incoming messages, the web service
provider will just need an incoming WSS4J interceptor and only the SOAP client
will need an outgoing one.</li></ol>
-
-
-<h2 id="WS-Security-AddingtheinterceptorsviatheAPI">Adding the interceptors
via the API</h2>
-
-<p>On the Server side, you'll want to add the interceptors to your CXF
Endpoint. If you're publishing your service using the JAX-WS APIs, you can get
your CXF endpoint like this:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-import org.apache.cxf.endpoint.Endpoint;
+<div id="ConfluenceContent"><h1
id="WS-Security-WS-Security">WS-Security</h1><p>WS-Security provides means to
secure your services above and beyond transport level protocols such as HTTPS.
Through a number of standards such as XML-Encryption, and headers defined in
the WS-Security standard, it allows you to:</p><ul><li>Pass authentication
tokens between services</li><li>Encrypt messages or parts of
messages</li><li>Sign messages</li><li>Timestamp messages</li><li>Manage public
keys using <a shape="rect"
href="http://cxf.apache.org/docs/xml-key-management-service-xkms.html";>XKMS</a></li></ul><p>CXF
relies on <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j";>WSS4J</a> in large part to implement
WS-Security. Within your own services, WS-Security can be activated by using <a
shape="rect"
href="http://cxf.apache.org/docs/ws-securitypolicy.html";>WS-SecurityPolicy</a>,
which provides a comprehensive and sophisticated validation of the security
properties of a received
message. A non-WS-SecurityPolicy approach is usually also possible by way of
CXF interceptors added to your service and/or client as detailed in this
article.</p><p>Please note that there are some incompatibilities between WSS4J
1.6.x (used by Apache CXF 2.6.x and 2.7.x) and 2.0.x (used by Apache CXF 3.0.x
and 3.1.x). The examples and links on this page mainly pertain to WSS4J 2.0.x
and hence CXF 3.0.x. For more information on the changes in WSS4J 2.0.x please
see the following <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/migration.html";>migration page</a>.</p><h1
id="WS-Security-Overviewofencryptionandsigning">Overview of encryption and
signing</h1><p>WS-Security makes heavy use of public/private key cryptography.
To really understand how to configure WS-Security, it is helpful - if not
necessary - to understand these basics. The Wikipedia has an <a shape="rect"
class="external-link"
href="http://en.wikipedia.org/wiki/Public-key_cryptography"; rel="nofollo
w">excellent entry</a> on this, but we'll try to summarize the relevant basics
here (This content is a modified version of the wikipedia content..)</p><p>With
public key cryptography, a user has a pair of public and private keys. These
are generated using a large prime number and a key function.<br clear="none">
<img class="confluence-embedded-image confluence-external-resource"
src="http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Public_key_making.svg/250px-Public_key_making.svg.png";
data-image-src="http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Public_key_making.svg/250px-Public_key_making.svg.png";></p><p>The
keys are related mathematically, but cannot be derived from one another. With
these keys we can encrypt messages. For example, if Bob wants to send a message
to Alice, he can encrypt a message using her public key. Alice can then decrypt
this message using her private key. Only Alice can decrypt this message as she
is the only one with the private key.<br c
lear="none"> <img class="confluence-embedded-image
confluence-external-resource"
src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f9/Public_key_encryption.svg/280px-Public_key_encryption.svg.png";
data-image-src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f9/Public_key_encryption.svg/280px-Public_key_encryption.svg.png";></p><p>Messages
can also be signed. This allows you to ensure the authenticity of the message.
If Alice wants to send a message to Bob, and Bob wants to be sure that it is
from Alice, Alice can sign the message using her private key. Bob can then
verify that the message is from Alice by using her public key.<br clear="none">
<img class="confluence-embedded-image confluence-external-resource"
src="http://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/Public_key_signing.svg/280px-Public_key_signing.svg.png";
data-image-src="http://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/Public_key_signing.svg/280px-Public_key_signing.svg.png";></p><h1
id=
"WS-Security-ConfiguringtheWSS4JInterceptors">Configuring the WSS4J
Interceptors</h1><p>To enable WS-Security within CXF for a server or a client,
you'll need to set up the WSS4J interceptors. You can either do this via the
API for standalone web services or via Spring XML configuration for
servlet-hosted ones. This section will provide an overview of how to do this,
and the following sections will go into more detail about configuring the
interceptors for specific security actions.</p><p>It is important to note
that:</p><ol><li>If you are using CXF 2.0.x, you must add the
SAAJ(In/Out)Interceptors if you're using WS-Security (This is done
automatically for you from CXF 2.1 onwards). These enable creation of a DOM
tree for each request/response. The support libraries for WS-Security require
DOM trees.</li><li>The web service provider may not need both in and out
WS-Security interceptors. For instance, if you are just requiring signatures on
incoming messages, the web service provider
will just need an incoming WSS4J interceptor and only the SOAP client will
need an outgoing one.</li></ol><h2
id="WS-Security-AddingtheinterceptorsviatheAPI">Adding the interceptors via the
API</h2><p>On the Server side, you'll want to add the interceptors to your CXF
Endpoint. If you're publishing your service using the JAX-WS APIs, you can get
your CXF endpoint like this:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[import org.apache.cxf.endpoint.Endpoint;
import org.apache.cxf.jaxws.EndpointImpl;
-EndpointImpl jaxWsEndpoint = (EndpointImpl)
Endpoint.publish("http://host/service",
- myServiceImpl);
+EndpointImpl jaxWsEndpoint = (EndpointImpl)
Endpoint.publish("http://host/service", myServiceImpl);
Endpoint cxfEndpoint = jaxWsEndpoint.getServer().getEndpoint();
]]></script>
-</div></div>
-<p>If you've used the (JaxWs)ServerFactoryBean, you can simply access it via
the Server object:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-import org.apache.cxf.endpoint.Endpoint;
+</div></div><p>If you've used the (JaxWs)ServerFactoryBean, you can simply
access it via the Server object:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[import org.apache.cxf.endpoint.Endpoint;
import org.apache.cxf.endpoint.Server;
import org.apache.cxf.frontend.ServerFactoryBean;
@@ -171,11 +134,8 @@ ServerFactoryBean factory = ...;
Server server = factory.create();
Endpoint cxfEndpoint = server.getEndpoint();
]]></script>
-</div></div>
-<p>On the client side, you can obtain a reference to the CXF endpoint using
the ClientProxy helper:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-import org.apache.cxf.frontend.ClientProxy;
+</div></div><p>On the client side, you can obtain a reference to the CXF
endpoint using the ClientProxy helper:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[import org.apache.cxf.frontend.ClientProxy;
...
GreeterService gs = new GreeterService();
@@ -184,15 +144,12 @@ Greeter greeter = gs.getGreeterPort();
org.apache.cxf.endpoint.Client client = ClientProxy.getClient(greeter);
org.apache.cxf.endpoint.Endpoint cxfEndpoint = client.getEndpoint();
]]></script>
-</div></div>
-<p><span class="confluence-anchor-link"
id="WS-Security-addinterceptors"></span>Now you're ready to add the
interceptors:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-import org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor;
+</div></div><p><span class="confluence-anchor-link"
id="WS-Security-addinterceptors"></span>Now you're ready to add the
interceptors:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[import
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor;
import org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor;
...
-Map<String,Object> inProps= new HashMap<String,Object>();
+Map<String,Object> inProps = new HashMap<String,Object>();
... // how to configure the properties is outlined below;
WSS4JInInterceptor wssIn = new WSS4JInInterceptor(inProps);
@@ -204,14 +161,8 @@ Map<String,Object> outProps = new
WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProps);
cxfEndpoint.getOutInterceptors().add(wssOut);
]]></script>
-</div></div>
-
-<h1 id="WS-Security-SpringXMLConfiguration">Spring XML Configuration</h1>
-
-<p>If you're using Spring to build endpoints (e.g., web services running on a
servlet container such as Tomcat), you can easily accomplish the above using
your bean definitions instead.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[
-<import resource="classpath:META-INF/cxf/cxf.xml" />
+</div></div><h1 id="WS-Security-SpringXMLConfiguration">Spring XML
Configuration</h1><p>If you're using Spring to build endpoints (e.g., web
services running on a servlet container such as Tomcat), you can easily
accomplish the above using your bean definitions instead.</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[<import
resource="classpath:META-INF/cxf/cxf.xml" />
<import resource="classpath*:META-INF/cxf/cxf-extension-*.xml"
/>
<jaxws:endpoint id="myService"
@@ -238,15 +189,8 @@ cxfEndpoint.getOutInterceptors().add(wss
</jaxws:inInterceptors>
</jaxws:endpoint>
]]></script>
-</div></div>
-
-<p>The entry keys and values given in the constructor-arg element above
(action, signaturePropFile, etc.) map to the text strings in WSS4J's <a
shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/handler/WSHandlerConstants.html";>WSHandlerConstants</a>
and <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/WSConstants.html";>WSConstants</a>
classes for the corresponding WSHandlerConstants.XXXXX and WSConstants.XXXX
constants you see in the section below (also see the WSS4J configuration <a
shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/config.html";>page</a>). So by viewing
WSHandlerConstants, for example, you can see that the
WSHandlerConstants.USERNAME_TOKEN value given below would need to be
"UsernameToken" instead when doing Spring configuration.</p>
-
-<p>If you want to avoid looking up the text keys for the
WSHandlerConstants.XXXXX and WSConstants.XXXX constants, you can also use the
Spring util namespace to reference static constants in your Spring context as
shown below.</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[
-<beans
+</div></div><p>The entry keys and values given in the constructor-arg element
above (action, signaturePropFile, etc.) map to the text strings in WSS4J's <a
shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/wss4j/dom/handler/WSHandlerConstants.html";>WSHandlerConstants</a>
and <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/wss4j/dom/WSConstants.html";>WSConstants</a>
classes for the corresponding WSHandlerConstants.XXXXX and WSConstants.XXXX
constants you see in the section below (also see the WSS4J configuration <a
shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/config.html";>page</a>). So by viewing
WSHandlerConstants, for example, you can see that the
WSHandlerConstants.USERNAME_TOKEN value given below would need to be
"UsernameToken" instead when doing Spring configuration.</p><p>If you want to
avoid looking up the text keys for the WSHandlerConstants.XXXXX and
WSConstants.XXXX consta
nts, you can also use the Spring util namespace to reference static constants
in your Spring context as shown below.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[<beans
...
xmlns:util="http://www.springframework.org/schema/util"
...
@@ -263,7 +207,7 @@ cxfEndpoint.getOutInterceptors().add(wss
<entry value="UsernameToken">
<key>
<util:constant
-
static-field="org.apache.ws.security.handler.WSHandlerConstants.ACTION"/>
+
static-field="org.apache.wss4j.dom.handler.WSHandlerConstants.ACTION"/>
</key>
</entry>
...
@@ -273,19 +217,8 @@ cxfEndpoint.getOutInterceptors().add(wss
...
]]></script>
-</div></div>
-
-<h2 id="WS-Security-AdditionalConfigurationOptions">Additional Configuration
Options</h2>
-
-<p>While the CXF WSS4J interceptors support the standard configuration
properties available in WSHandlerConstants.XXXXX and WSConstants.XXXX, CXF also
provides access to some additional low level configuration capabilities in
WSS4J and some other security related interceptors.</p>
-
-<h3
id="WS-Security-ValidatingSignatureand/orEncryptionofMessageContents">Validating
Signature and/or Encryption of Message Contents</h3>
-
-<p>As of CXF 2.2.8, the CryptoCoverageChecker interceptor allows one to
validate signature and encryption coverage of message contents without
migrating to a WS-SecurityPolicy based configuration. The interceptor can
support enforcement of signature and encryption coverage at both the element
and content level (be aware that the combination of signature and content do
not represent a valid combination of coverage type and coverage scope). To
configure this interceptor using the API, follow the example below.</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-import org.apache.cxf.ws.security.wss4j.CryptoCoverageChecker;
+</div></div><h2 id="WS-Security-AdditionalConfigurationOptions">Additional
Configuration Options</h2><p>While the CXF WSS4J interceptors support the
standard configuration properties available in WSHandlerConstants.XXXXX and
WSConstants.XXXX, CXF also provides access to some additional low level
configuration capabilities in WSS4J and some other security related
interceptors.</p><h3
id="WS-Security-ValidatingSignatureand/orEncryptionofMessageContents">Validating
Signature and/or Encryption of Message Contents</h3><p>As of CXF 2.2.8, the
CryptoCoverageChecker interceptor allows one to validate signature and
encryption coverage of message contents without migrating to a
WS-SecurityPolicy based configuration. The interceptor can support enforcement
of signature and encryption coverage at both the element and content level (be
aware that the combination of signature and content do not represent a valid
combination of coverage type and coverage scope). To configure this interceptor
using
the API, follow the example below.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[import
org.apache.cxf.ws.security.wss4j.CryptoCoverageChecker;
import org.apache.cxf.ws.security.wss4j.CryptoCoverageChecker.XPathExpression;
import org.apache.cxf.ws.security.wss4j.CryptoCoverageUtil.CoverageScope;
import org.apache.cxf.ws.security.wss4j.CryptoCoverageUtil.CoverageType;
@@ -302,19 +235,8 @@ List<XPathExpression> xpaths = Arr
CryptoCoverageChecker checker = new CryptoCoverageChecker(prefixes, xpaths);
]]></script>
-</div></div>
-
-<p>The interceptor can also be configured in Spring using the conventional
bean definition format.</p>
-
-<p>After configuring the interceptor as above, simply add the interceptor to
your client or server interceptor chain as shown previously 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 pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[
-<jaxws:inInterceptors>
+</div></div><p>The interceptor can also be configured in Spring using the
conventional bean definition format.</p><p>After configuring the interceptor as
above, simply add the interceptor to your client or server interceptor chain as
shown previously 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 con
figuation 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 pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[<jaxws:inInterceptors>
<bean
class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
<constructor-arg>
<map>
@@ -327,17 +249,8 @@ CryptoCoverageChecker checker = new Cryp
<bean
class="org.apache.cxf.ws.security.wss4j.DefaultCryptoCoverageChecker"/>
</jaxws:inInterceptors>
]]></script>
-</div></div>
-
-<p>As of CXF 2.5.11, 2.6.8 and 2.7.5, it is possible to only check that a
received message meets cryptographic requirements via the CryptoCoverageChecker
if it is not a fault. This is useful in the scenario where a client is using
the CryptoCoverageChecker interceptor to verify security requirements from a
service response. In this scenario, you may want to get the original service
Fault rather than have the CryptoCoverageChecker throw an exception if a Fault
message from the service isn't secured. To enable this behaviour, then set the
"checkFaults" boolean property on CryptoCoverageChecker to "false".</p>
-
-<h3 id="WS-Security-CustomProcessors">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
configuration can be achieved through the API as well. The key value is an XML
qualified name of the WS-Security 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-Security header element.</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[
-<bean
class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
+</div></div><p>As of CXF 2.5.11, 2.6.8 and 2.7.5, it is possible to only check
that a received message meets cryptographic requirements via the
CryptoCoverageChecker if it is not a fault. This is useful in the scenario
where a client is using the CryptoCoverageChecker interceptor to verify
security requirements from a service response. In this scenario, you may want
to get the original service Fault rather than have the CryptoCoverageChecker
throw an exception if a Fault message from the service isn't secured. To enable
this behaviour, then set the "checkFaults" boolean property on
CryptoCoverageChecker to "false".</p><h3
id="WS-Security-CustomProcessors">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 configuration can b
e achieved through the API as well. The key value is an XML qualified name of
the WS-Security 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-Security header element.</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[<bean
class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
<constructor-arg>
<map>
...
@@ -360,15 +273,8 @@ CryptoCoverageChecker checker = new Cryp
</constructor-arg>
</bean>
]]></script>
-</div></div>
-
-<h3 id="WS-Security-CustomActions">Custom Actions</h3>
-
-<p>As of CXF 2.2.6, you can specify custom WSS4J Action configurations on the
WSS4JOutInterceptor. To activate this configuration option, one provides a
non-WSS4J defined property, wss4j.action.map, to the WSS4JOutInterceptor as
shown in the following Spring example. The same configuration can be achieved
through the API as well. The key value is an integer representing the WSS4J
action identifier. The entry values can be a String representing a class name
of the action to instantiate or an Object implementing Action. This
configuration option allows you to override built-in action implementations or
add your own.</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[
-<bean
class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
+</div></div><h3 id="WS-Security-CustomActions">Custom Actions</h3><p>As of CXF
2.2.6, you can specify custom WSS4J Action configurations on the
WSS4JOutInterceptor. To activate this configuration option, one provides a
non-WSS4J defined property, wss4j.action.map, to the WSS4JOutInterceptor as
shown in the following Spring example. The same configuration can be achieved
through the API as well. The key value is an integer representing the WSS4J
action identifier. The entry values can be a String representing a class name
of the action to instantiate or an Object implementing Action. This
configuration option allows you to override built-in action implementations or
add your own.</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: xml; gutter: false"
type="syntaxhighlighter"><![CDATA[<bean
class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
<constructor-arg>
<map>
...
@@ -383,25 +289,8 @@ CryptoCoverageChecker checker = new Cryp
</constructor-arg>
</bean>
]]></script>
-</div></div>
-
-<p>For the case that adding new custom action, if the new key int number is
12345, you must also specify new action name as string "12345".</p>
-
-<h1 id="WS-Security-ConfiguringWS-SecurityActions">Configuring WS-Security
Actions</h1>
-
-<h2 id="WS-Security-UsernameTokenAuthentication">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. </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" - Whether to cache UsernameToken
nonces. 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. See <a shape="rect"
href="http://cxf.apache.org/javadoc/latest/org/apache/cxf/ws/security/SecurityConstants.html#ENABLE_NONCE_CACHE";>here</a>
for more information.</li><li>"ws-security.nonce.cache.instance" - This holds
a reference to a <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/cache/ReplayCache.html";>ReplayCache</a>
instance used to cache UsernameToken nonces. The default instance that is used
is the <a shape="rect" class="external-link"
href="http://svn.apache.org/viewvc/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/cache/EHCacheReplayCache.java?view=markup";>EHCacheReplayCache</a>.</li><li>"ws-security.cache.config.file"
- Set th
is property to point to a configuration file for the underlying caching
implementation. The default configuration file that is used is <a shape="rect"
class="external-link"
href="http://svn.apache.org/viewvc/cxf/trunk/rt/ws/security/src/main/resources/cxf-ehcache.xml?view=markup";>cxf-ehcache.xml</a>
in the cxf-rt-ws-security module.</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 pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-inProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
+</div></div><p>For the case that adding new custom action, if the new key int
number is 12345, you must also specify new action name as string
"12345".</p><h1 id="WS-Security-ConfiguringWS-SecurityActions">Configuring
WS-Security Actions</h1><h2
id="WS-Security-UsernameTokenAuthentication">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.</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" - Whether to cache
UsernameToken nonces. 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. See <a
shape="rect"
href="http://cxf.apache.org/javadoc/latest/org/apache/cxf/ws/security/SecurityConstants.html#ENABLE_NONCE_CACHE";>here</a>
for more information.</li><li>"ws-security.nonce.cache.instance" - This holds
a reference to a <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/wss4j/common/cache/ReplayCache.html";>ReplayCache</a>
instance used to cache UsernameToken nonces. The default instance that is used
is the <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/wss4j/common/cache/EHCa
cheReplayCache.html">EHCacheReplayCache</a>.</li><li>"ws-security.cache.config.file"
- Set this property to point to a configuration file for the underlying
caching implementation. The default configuration file that is used is <a
shape="rect" class="external-link"
href="http://svn.apache.org/viewvc/cxf/trunk/rt/ws/security/src/main/resources/cxf-ehcache.xml?view=markup";>cxf-ehcache.xml</a>
in the cxf-rt-ws-security module.</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 pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[inProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
// Password type : plain text
inProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_TEXT);
// for hashed password use:
@@ -410,16 +299,12 @@ inProps.put(WSHandlerConstants.PASSWORD_
inProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ServerPasswordHandler.class.getName());
]]></script>
-</div></div>
-
-<p>The password callback class allows you to retrieve the password for a given
user so that WS-Security can determine if they're authorized. Here is a small
example:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-import java.io.IOException;
+</div></div><p>The password callback class allows you to retrieve the password
for a given user so that WS-Security can determine if they're authorized. Here
is a small example:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[import java.io.IOException;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
-import org.apache.ws.security.WSPasswordCallback;
+import org.apache.wss4j.common.ext.WSPasswordCallback;
public class ServerPasswordCallback implements CallbackHandler {
@@ -437,11 +322,8 @@ public class ServerPasswordCallback impl
}
]]></script>
-</div></div>
-<p>Note that for up to and including CXF 2.3.x, the password validation of the
special case of a plain-text password (or any other yet unknown password type)
is delegated to the callback class, see <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/processor/UsernameTokenProcessor.html#handleUsernameToken(org.w3c.dom.Element,%20javax.security.auth.callback.CallbackHandler)">org.apache.ws.security.processor.UsernameTokenProcessor#handleUsernameToken()
method javadoc</a> of the <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/";>WSS4J</a> project. In that case, the
ServerPasswordCallback should be something like the following one:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-public class ServerPasswordCallback implements CallbackHandler {
+</div></div><p>Note that for up to and including CXF 2.3.x, the password
validation of the special case of a plain-text password (or any other yet
unknown password type) is delegated to the callback class. In that case, the
ServerPasswordCallback should be something like the following one:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[public class ServerPasswordCallback
implements CallbackHandler {
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
@@ -457,12 +339,8 @@ public class ServerPasswordCallback impl
}
]]></script>
-</div></div>
-<p>For CXF 2.4 onwards, the callback handler supplies the password for all
cases, and the validation is done internally (but can be configured). See <a
shape="rect" class="external-link"
href="http://coheigea.blogspot.com/2011/02/usernametoken-processing-changes-in.html";
rel="nofollow">here</a> for more information.<br clear="none">
-On the Client side you'll want to configure the WSS4J outgoing properties:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-outProps.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
+</div></div><p>For CXF 2.4 onwards, the callback handler supplies the password
for all cases, and the validation is done internally (but can be configured).
See <a shape="rect" class="external-link"
href="http://coheigea.blogspot.com/2011/02/usernametoken-processing-changes-in.html";
rel="nofollow">here</a> for more information.<br clear="none"> On the Client
side you'll want to configure the WSS4J outgoing properties:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
// Specify our username
outProps.put(WSHandlerConstants.USER, "joe");
// Password type : plain text
@@ -473,15 +351,12 @@ outProps.put(WSHandlerConstants.PASSWORD
outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientPasswordHandler.class.getName());
]]></script>
-</div></div>
-<p>Once again we're using a password callback, except this time instead of
specifying our password on the server side, we're specifying the password we
want sent with the message. This is so we don't have to store our password in
our configuration file.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-import java.io.IOException;
+</div></div><p>Once again we're using a password callback, except this time
instead of specifying our password on the server side, we're specifying the
password we want sent with the message. This is so we don't have to store our
password in our configuration file.</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[import java.io.IOException;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
-import org.apache.ws.security.WSPasswordCallback;
+import org.apache.wss4j.common.ext.WSPasswordCallback;
public class ClientPasswordCallback implements CallbackHandler {
@@ -496,130 +371,60 @@ public class ClientPasswordCallback impl
}
]]></script>
-</div></div>
-
-<p>In the case of multiple users with different passwords, use the <a
shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/WSPasswordCallback.html";>WSPasswordCallback</a>'s
getIdentifier() method to obtain the username of the current SOAP request.</p>
-
-<p><a shape="rect" class="external-link"
href="http://depressedprogrammer.wordpress.com/2007/07/31/cxf-ws-security-using-jsr-181-interceptor-annotations-xfire-migration/";
rel="nofollow">Here is an example</a> of WS-Security implemented using
annotations for interceptors (uses UsernameToken).</p>
-
-<h3
id="WS-Security-WS-SecurityUsernameTokenandCustomAuthentication">WS-Security
UsernameToken and Custom Authentication</h3>
-
-<p>If needed, one may want to configure a jaxws:endpoint with a
"ws-security.validate.token" property set to false and register a custom
org.apache.cxf.interceptor.security.AbstractUsernameTokenInInterceptor
implementation for using a WSS4J UsernameToken wrapped in a CXF specific
UsernameToken for the custom authentication and Subject creation. The
JAASLoginInterceptor will also recognize a CXF UsernameToken and thus can be
used instead of the custom
org.apache.cxf.interceptor.security.AbstractUsernameTokenInterceptor. (Prior
to CXF 2.4.0, use "ws-security.ut.no-callbacks" instead of
"ws-security.validate.token" with the value of true instead of false to
postpone the validation of the token.)</p>
-
-<h2 id="WS-Security-UsingX.509Certificates">Using X.509 Certificates</h2>
-
-<p>The X.509 Certificate Token Profile (<a shape="rect" class="external-link"
href="http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf";
rel="nofollow">pdf</a>) provides another option for implementing WS-Security.
For the Signature and Encryption actions, you'll need to create a public &
private key for the entities involved. You can generate a self-signed key pair
for your development environment via the following steps. Keep in mind these
will not be signed by an external authority like Verisign, so are inappropriate
for production use.</p>
-
-<p>1. Creating private key with given alias and password like
"myAlias"/"myAliasPassword" in keystore (protected by password for<br
clear="none">
-security reasons)</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-keytool -genkey -alias myAlias -keypass myAliasPassword -keystore \
+</div></div><p>In the case of multiple users with different passwords, use the
<a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/apidocs/org/apache/wss4j/common/ext/WSPasswordCallback.html";>WSPasswordCallback</a>'s
getIdentifier() method to obtain the username of the current SOAP
request.</p><p><a shape="rect" class="external-link"
href="http://depressedprogrammer.wordpress.com/2007/07/31/cxf-ws-security-using-jsr-181-interceptor-annotations-xfire-migration/";
rel="nofollow">Here is an example</a> of WS-Security implemented using
annotations for interceptors (uses UsernameToken).</p><h3
id="WS-Security-WS-SecurityUsernameTokenandCustomAuthentication">WS-Security
UsernameToken and Custom Authentication</h3><p>If needed, one may want to
configure a jaxws:endpoint with a "ws-security.validate.token" property set to
false and register a custom
org.apache.cxf.interceptor.security.AbstractUsernameTokenInInterceptor
implementation for using a WSS4J UsernameToken wrapped
in a CXF specific UsernameToken for the custom authentication and Subject
creation. The JAASLoginInterceptor will also recognize a CXF UsernameToken and
thus can be used instead of the custom
org.apache.cxf.interceptor.security.AbstractUsernameTokenInterceptor. (Prior to
CXF 2.4.0, use "ws-security.ut.no-callbacks" instead of
"ws-security.validate.token" with the value of true instead of false to
postpone the validation of the token.)</p><h2
id="WS-Security-UsingX.509Certificates">Using X.509 Certificates</h2><p>The
X.509 Certificate Token Profile (<a shape="rect" class="external-link"
href="http://www.oasis-open.org/committees/download.php/16785/wss-v1.1-spec-os-x509TokenProfile.pdf";
rel="nofollow">pdf</a>) provides another option for implementing WS-Security.
For the Signature and Encryption actions, you'll need to create a public &
private key for the entities involved. You can generate a self-signed key pair
for your development environment via the following steps. Keep in
mind these will not be signed by an external authority like Verisign, so are
inappropriate for production use.</p><p>1. Creating private key with given
alias and password like "myAlias"/"myAliasPassword" in keystore (protected by
password for<br clear="none"> security reasons)</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[keytool -genkey -alias myAlias -keypass
myAliasPassword -keystore \
privatestore.jks -storepass keyStorePassword -dname "cn=myAlias"
-keyalg RSA
]]></script>
-</div></div>
-<p>The alias is simply a way to identify the key pair. In this instance we are
using the RSA algorithm.</p>
-
-<p>2. Self-sign our certificate (in production environment this will be done
by a company like Verisign).</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-keytool -selfcert -alias myAlias -keystore privatestore.jks \
+</div></div><p>The alias is simply a way to identify the key pair. In this
instance we are using the RSA algorithm.</p><p>2. Self-sign our certificate (in
production environment this will be done by a company like Verisign).</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[keytool -selfcert -alias myAlias -keystore
privatestore.jks \
-storepass keyStorePassword -keypass myAliasPassword
]]></script>
-</div></div>
-<p>3. Export the public key from our private keystore to file named key.rsa</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-keytool -export -alias myAlias -file key.rsa -keystore privatestore.jks \
+</div></div><p>3. Export the public key from our private keystore to file
named key.rsa</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[keytool -export -alias myAlias -file key.rsa
-keystore privatestore.jks \
-storepass keyStorePassword
]]></script>
-</div></div>
-<p>4. Import the public key to new keystore:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-keytool -import -alias myAlias -file key.rsa -keystore publicstore.jks \
+</div></div><p>4. Import the public key to new keystore:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[keytool -import -alias myAlias -file key.rsa
-keystore publicstore.jks \
-storepass keyStorePassword
]]></script>
-</div></div>
-<p>So now we have two keystores containing our keys - a public one
(publicstore.jks) and a private one (privatestore.jks). Both of them have
keystore password set to keyStorePass (this not recommended for production but
ok for development) and alias set to myAlias. The file key.rsa can removed from
filesystem, since it used only temporarily. Storing keys in keystores is
strongly advised because a keystore is protected by a password.</p>
-
-<p>A more detailed description of key generation can be found here:<br
clear="none">
-<a shape="rect" class="external-link"
href="http://java.sun.com/javase/6/docs/technotes/tools/solaris/keytool.html";
rel="nofollow">http://java.sun.com/javase/6/docs/technotes/tools/solaris/keytool.html</a></p>
-
-<p>How to create a production certificate can be found here:<br clear="none">
-<a shape="rect" class="external-link"
href="http://support.globalsign.net/en/objectsign/java.cfm";
rel="nofollow">http://support.globalsign.net/en/objectsign/java.cfm</a></p>
-
-<h3 id="WS-Security-Signing">Signing</h3>
-
-<p>Signing a message is used to validate to the recipient that the message
could only have come from a certain sender, and that the message was not
altered in transit. It involves the sender encrypting a digest (hash) of the
message with its private key, and the recipient decrypting the hash with the
sender's public key, and recalculating the digest of the message to make sure
the message was not altered in transit (i.e., that the digest values calculated
by both the sender and recipient are the same). For this process to occur you
must ensure that the Client's public key has been imported into the server's
keystore using keytool.</p>
-
-<p>On the client side, our outgoing WS-Security properties will look like so
(see <a shape="rect" href="#WS-Security-addinterceptors">above</a> for code
sample):</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-outProps.put(WSHandlerConstants.ACTION, "Signature");
+</div></div><p>So now we have two keystores containing our keys - a public one
(publicstore.jks) and a private one (privatestore.jks). Both of them have
keystore password set to keyStorePass (this not recommended for production but
ok for development) and alias set to myAlias. The file key.rsa can removed from
filesystem, since it used only temporarily. Storing keys in keystores is
strongly advised because a keystore is protected by a password.</p><p>A more
detailed description of key generation can be found here:<br clear="none"> <a
shape="rect" class="external-link"
href="http://java.sun.com/javase/6/docs/technotes/tools/solaris/keytool.html";
rel="nofollow">http://java.sun.com/javase/6/docs/technotes/tools/solaris/keytool.html</a></p><p>How
to create a production certificate can be found here:<br clear="none"> <a
shape="rect" class="external-link"
href="http://support.globalsign.net/en/objectsign/java.cfm";
rel="nofollow">http://support.globalsign.net/en/objectsign/java.cfm</a></p>
<h3 id="WS-Security-Signing">Signing</h3><p>Signing a message is used to
validate to the recipient that the message could only have come from a certain
sender, and that the message was not altered in transit. It involves the sender
encrypting a digest (hash) of the message with its private key, and the
recipient decrypting the hash with the sender's public key, and recalculating
the digest of the message to make sure the message was not altered in transit
(i.e., that the digest values calculated by both the sender and recipient are
the same). For this process to occur you must ensure that the Client's public
key has been imported into the server's keystore using keytool.</p><p>On the
client side, our outgoing WS-Security properties will look like so (see <a
shape="rect" href="#WS-Security-addinterceptors">above</a> for code
sample):</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[outProps.put(WSHandlerConstants.ACTION,
"Signature");
outProps.put(WSHandlerConstants.USER, "myAlias");
outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientCallbackHandler.class.getName());
outProps.put(WSHandlerConstants.SIG_PROP_FILE,
"client_sign.properties");
]]></script>
-</div></div>
-
-<p>The USER that is specified is the key alias for the client. The password
callback class is responsible for providing that key's password. </p>
-
- <div class="aui-message success shadowed information-macro">
+</div></div><p>The USER that is specified is the key alias for the client. The
password callback class is responsible for providing that key's password.</p>
<div class="aui-message success shadowed information-macro">
<p class="title">Tip</p>
<span class="aui-icon icon-success">Icon</span>
<div class="message-content">
- <p>For X.509 support you will normally have
multiple actions, e.g. Encryption with Signature. For these cases, just
space-separate the actions in the ACTION property as follows:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-outProps.put(WSHandlerConstants.ACTION,
+ <p>For X.509 support you will normally have
multiple actions, e.g. Encryption with Signature. For these cases, just
space-separate the actions in the ACTION property as follows:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.TIMESTAMP + " " +
WSHandlerConstants.SIGNATURE + " " +
WSHandlerConstants.ENCRYPT);
]]></script>
-</div></div>
-<p>Alternatively, you may space-separate the string literals you see above in
the Spring configuration (e.g., "Signature Encrypt")</p>
+</div></div><p>Alternatively, you may space-separate the string literals you
see above in the Spring configuration (e.g., "Signature Encrypt")</p>
</div>
</div>
-
-
-<p>Our client_sign.properties file contains several settings to configure
WSS4J:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
+<p>Our client_sign.properties file contains several settings to configure
WSS4J:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=keyStorePassword
org.apache.ws.security.crypto.merlin.keystore.alias=myAlias
org.apache.ws.security.crypto.merlin.keystore.file=client_keystore.jks
]]></script>
-</div></div>
-<p>On the server side, we need to configure our incoming WSS4J interceptor to
verify the signature using the Client's public key.</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-inProps.put(WSHandlerConstants.ACTION, "Signature");
+</div></div><p>On the server side, we need to configure our incoming WSS4J
interceptor to verify the signature using the Client's public key.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[inProps.put(WSHandlerConstants.ACTION,
"Signature");
inProps.put(WSHandlerConstants.SIG_PROP_FILE, "server.properties");
]]></script>
-</div></div>
-<p>Our server_sign.properties file contains several settings to configure
WSS4J:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[
-org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
+</div></div><p>Our server_sign.properties file contains several settings to
configure WSS4J:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false"
type="syntaxhighlighter"><![CDATA[org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=amex123
org.apache.ws.security.crypto.merlin.keystore.file=server_keystore.jks
]]></script>
-</div></div>
-
-<h3 id="WS-Security-Encryption">Encryption</h3>
-
-<p>Encryption involves the sender encrypting the message with the recipient's
public key to ensure that only the recipient can read the message (only the
recipient has its own private key, necessary for decrypting the message.) This
requires the sender to have the recipient's public key in its keystore.</p>
-
-<p>The process for encrypting is very similar to and indeed usually combined
with the signature process above. Our <a shape="rect" class="external-link"
href="http://svn.apache.org/viewvc/cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/security/";>WS-Security
test sample</a> (svn checkout <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/security/";>http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/security/</a>)
provides an example of encrypting requests and responses, also check <a
shape="rect" class="external-link"
href="http://www.jroller.com/gmazza/entry/cxf_x509_profile"; rel="nofollow">this
blog entry</a> for a more end-to-end example showing signature and encryption
of both SOAP requests and responses.</p>
-
-<h1 id="WS-Security-SecurityBestPractices">Security Best Practices</h1>
-
-<p>Some guidelines are given at the WSS4J website about <a shape="rect"
class="external-link" href="http://ws.apache.org/wss4j/best_practice.html";>best
practices</a> when using WS-Security. It is recommended to study the guidelines
carefully.</p></div>
+</div></div><h3 id="WS-Security-Encryption">Encryption</h3><p>Encryption
involves the sender encrypting the message with the recipient's public key to
ensure that only the recipient can read the message (only the recipient has its
own private key, necessary for decrypting the message.) This requires the
sender to have the recipient's public key in its keystore.</p><p>The process
for encrypting is very similar to and indeed usually combined with the
signature process above. Our <a shape="rect" class="external-link"
href="http://svn.apache.org/viewvc/cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/security/";>WS-Security
test sample</a> (svn checkout <a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/security/";>http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/security/</a>)
provides an example of encrypting requests
and responses, also check <a shape="rect" class="external-link"
href="http://www.jroller.com/gmazza/entry/cxf_x509_profile"; rel="nofollow">this
blog entry</a> for a more end-to-end example showing signature and encryption
of both SOAP requests and responses.</p><h1
id="WS-Security-SecurityBestPractices">Security Best Practices</h1><p>Some
guidelines are given at the WSS4J website about <a shape="rect"
class="external-link" href="http://ws.apache.org/wss4j/best_practice.html";>best
practices</a> when using WS-Security. It is recommended to study the guidelines
carefully.</p></div>
</div>
<!-- Content -->
</td>
![http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Public_key_making.svg/250px-Public_key_making.svg.png"](http://upload.wikimedia.org/wikipedia/commons/thumb/3/3f/Public_key_making.svg/250px-Public_key_making.svg.png"){kind=link}
![http://upload.wikimedia.org/wikipedia/commons/thumb/f/f9/Public_key_encryption.svg/280px-Public_key_encryption.svg.png"](http://upload.wikimedia.org/wikipedia/commons/thumb/f/f9/Public_key_encryption.svg/280px-Public_key_encryption.svg.png"){kind=link}
![http://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/Public_key_signing.svg/280px-Public_key_signing.svg.png"](http://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/Public_key_signing.svg/280px-Public_key_signing.svg.png"){kind=link}