Author: buildbot
Date: Wed Sep 13 19:57:20 2017
New Revision: 1018123
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
websites/production/cxf/content/cache/main.pageCache
websites/production/cxf/content/docs/30-migration-guide.html
websites/production/cxf/content/docs/jax-rs-data-bindings.html
websites/production/cxf/content/docs/json-support.html
websites/production/cxf/content/docs/securing-cxf-services.html
websites/production/cxf/content/docs/ws-security.html
websites/production/cxf/content/faq.html
websites/production/cxf/content/release-management.html
Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/docs/30-migration-guide.html
==============================================================================
--- websites/production/cxf/content/docs/30-migration-guide.html (original)
+++ websites/production/cxf/content/docs/30-migration-guide.html Wed Sep 13
19:57:20 2017
@@ -107,7 +107,7 @@ Apache CXF -- 3.0 Migration Guide
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><h2
id="id-3.0MigrationGuide-3.0MigrationGuide">3.0 Migration Guide</h2><h4
id="id-3.0MigrationGuide-JAX-RS">JAX-RS</h4><ul><li>JAX-RS 2.0 has been
completely implemented.</li><li>JAX-RS WADL auto-generation code has been moved
to a new cxf-rt-rs-service-description module.</li><li>JAX-RS 2.0 Client API
and CXF specific WebClient and Proxy client code is now available in a new
cxf-rt-rs-client module. Important: the namespace for jaxrs:client elements has
changed from "http://cxf.apache.org/jaxrs"; to
"http://cxf.apache.org/jaxrs-client";</li><li>CXF RequestHandler and
ResponseHandler filters have been removed, please use JAX-RS 2.0
ContainerRequestFilter and ContainerResponseFilter and also WriterInterceptor
and ReaderInterceptor when needed.</li><li>CXF JAX-RS Form extension has been
dropped, please use JAX-RS 2.0 Form.</li><li>CXF JAX-RS ParameterHandler has
been dropped, please use JAX-RS 2.0
ParamConverterProvider.</li><li>javax.annotation.Resource ann
otation can no longer be used to annotate JAX-RS context properties. Only
javax.ws.rs.core.Context annotation is supported from now on.</li></ul><h4
id="id-3.0MigrationGuide-JAX-WS/Soap">JAX-WS/Soap</h4><ul><li>Add new code
generator frontend to add CXF specific constructors and methods. (pass "-fe
cxf" to wsdl2java)</li><li>Make AbstractFeature subclass WebServiceFeature and
update the JAX-WS frontend to look for
them.</li><li>"jaxb-validation-event-handler"s now apply for both Reading and
Writing. (previously only applied to Reading). There are separate
jaxb-(reader|writer)-validation-event-handler properties if you need it set for
only one direction.</li><li>If the WSDL location that is passed into CXF is not
valid, previous versions of CXF *MAY* ignore the error and proceed as if "null"
was passed for the WSDL.   3.0 will now throw an
exception.</li><li>ClientProxy.getClient(proxy) is no longer needed for most
use cases.  The client proxy instances now implement the Cl
ient API directly.   A direct cast to Client should work.</li></ul><h4
id="id-3.0MigrationGuide-Transports">Transports</h4><ul><li>Support for the
older JMS 1.0.2 API's has been removed.   Your JMS provider must support
the 1.1 API's. </li><li>A new WebSocket based transport has been
added</li><li>Support for Netty based HTTP servers and clients has been
added</li></ul><h4 id="id-3.0MigrationGuide-BeanValidation">Bean
Validation</h4><p>Bean Validation 1.1 interceptors and features have been
introduced for JAX-RS and JAX-WS frontends.</p><h4
id="id-3.0MigrationGuide-WS-Security">WS-Security</h4><ul><li>The
DefaultCryptoCoverageChecker now contains boolean properties to easily check if
a WSS UsernameToken was signed and/or encrypted. The default is now that a
UsernameToken must be encrypted.</li><li>CXF 3.0.x picks up a new major version
of Apache WSS4J (2.0.0). There are some changes in this release which will
impact on existing CXF users. These changes are extensively
summarized in the <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/migration.html";>WSS4J 2.0.0 Migration
Guide</a>. The major changes are as follows:<br clear="none"><ul><li>If you
have implemented a CallbackHandler to set/retrieve passwords for
UsernameTokens/Signatures/Decryption/etc., then the namespace of the
WSPasswordCallback Object has changed from "org.apache.ws.security" to
"org.apache.wss4j.common.ext".</li><li>If you have implemented a
CallbackHandler to create SAML Assertions, then the namespace of the SAML bean
objects has changed from "org.apache.ws.security.saml.ext" to
"org.apache.wss4j.common.saml". </li><li>WSS4J 1.6.x used a saml
properties file to sign a SAML Assertion. This has been removed in WSS4J 2.0.0.
Instead the SAMLCallback Object contains additional properties that can be set
to sign the Assertion. Please see the section entitled "SAML Assertion changes"
in the <a shape="rect" class="external-link" href="http://ws.apache.
org/wss4j/migration.html">WSS4J 2.0.0 Migration Guide</a> for more information
on this.</li><li>A small number of configuration tags have been removed in
WSS4J 2.0.0. Please see the section entitled "Removed Configuration Tags in
WSS4J 2.0.0" in the <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/migration.html";>WSS4J 2.0.0 Migration
Guide</a> for more information on this.</li><li>The default namespace for
derived keys and secure conversation is now  "<span
class="nolink">http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512</span>".
The older namespace can be used instead via a new configuration
tag.</li><li>The RSA v1.5 Key Transport algorithm is no longer allowed by
default. This can be changed via a configuration tag.</li><li>Turning off BSP
(Basic Security Profile) Compliance (Basic Security Profile) on the outbound
side no longer has the effect of disabling the addition of a
InclusiveNamespaces PrefixList when signing a portion of the m
essage. This is now controlled by a separate configuration tag in WSS4J
2.0.0.</li></ul></li><li>In addition to the changes above, CXF 3.0.0 fully
supports the new streaming (StAX-based) WS-Security implementation in WSS4J
2.0.0.</li><li>To switch to use the streaming code for the manual "Action"
based approach, simply change the outbound and inbound interceptors as
follows:<ul><li>"org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor" to
"org.apache.cxf.ws.security.wss4j.WSS4JStaxOutInterceptor".</li><li>"org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"
to
"org.apache.cxf.ws.security.wss4j.WSS4JStaxInInterceptor".</li></ul></li><li>For
the WS-SecurityPolicy based approach of configuring WS-Security, simply set
the JAX-WS property SecurityConstants.ENABLE_STREAMING_SECURITY
("ws-security.enable.streaming") to "true". For more information on the
streaming functionality available in WSS4J 2.0.0, please see the <a
shape="rect" class="external-link" href="http://ws.apache.org/wss4j/
streaming.html">streaming documentation</a> page of WSS4J.</li></ul><h4
id="id-3.0MigrationGuide-WS-ReliableMessaging">WS-ReliableMessaging</h4><ul><li>The
WS-RM subsystem has been updated to more completely implement the 1.1
specification.  </li><li>Closing a client proxy via
((Closable)proxy).close() will now terminate open sequences.</li></ul><h4
id="id-3.0MigrationGuide-Majordependencychanges">Major dependency
changes</h4><ul><li>Spring 3.2 or newer is required.   The calls to the
API's that were deprecated in Spring 3.x have been removed.  This allows
CXF 3.0 to work with Spring 4, but means it can no longer work with Spring
2.5.</li></ul><h4 id="id-3.0MigrationGuide-CXFModule/JarChanges">CXF Module/Jar
Changes</h4><ul><li>Combined api/core into just a cxf-core. All "wsdl" related
stuff has been moved to a new cxf-wsdl bundle to remove the wsdl4j requirement
for JAX-RS applications.</li><li>Dropped support for Karaf 2.2.x. Karaf 2.3.x
is now required.</li><li>The
direct dependency on a javax.mail implementation has been removed and the CXF
maven poms will not pull one in transitively anymore. For MOST users, this is
not a problem. However, if your application uses MTOM or Soap w/Attachments or
similar that requires some of the DataContentHandlers that are part of the mail
implementations, you may need to re-add this to your
classpath.</li><li>DynamicClientFactory was moved from the JAXB databinding to
the Simple frontend. However, users are strongly encouraged to use the
JaxWsDynamicClientFactory subclass.</li><li>The large bundle jar has been
removed due to maintenance issues as well as new functionality not being usable
from the bundle jar.  Users should upgrade to the individual modules that
they need for their application.</li></ul><h4
id="id-3.0MigrationGuide-Removed/ChangedAPI's">Removed/Changed
API's</h4><ul><li>CXFBusImpl has been removed. The only subclass was the
ExtensionManagerBus (SpringBus and Blueprint/osgi stuff subclas
sed that) so the functionality was pushed up into ExtensionManagerBus. Some of
the "common" methods were put directly on the Bus interface to make using the
Bus cleaner (no casts to the impl).</li><li>The unused "run()" method on Bus
was removed.</li><li>Merge BaseDataReader/DataReader and the same for the
writer, getting rid of the "Base" versions that are unreferenced.</li><li>The 2
unused params on Destination.getBackChannel were removed. They were unused and
normally passed in as null.</li><li>Remove QueryHandlers -> these were
originally used for the ?wsdl processing (and is still used for ?js). However,
that stuff is better done directly on the interceptor chains as interceptors to
allow user supplied interceptors to also handle them. I'd like to just remove
these. (obviously update the ?js stuff) Would simplify the CXFServlet a
bit.</li><li>Removed all the /META-INF/cxf/cxf-extension-XYZ.xml files. They
have been deprecated and not needed for a long time.</li><li>Updated C
onduitInitiator and DestinationFactory to pass Bus as parameter to the various
methods.</li><li>Removed support for the old bus-extensions.xml file (in favor
of the current and much faster bus-extensions.txt)</li><li>Move ALL XML parsing
and writing to StaxUtils and DOM based utilities to DOMUtils. The XMLUtils
class that used SAX based parsing and Transformer based writing has been
eliminated. This simplifies the code as well as increases security as we can
provide better limits and have more control with the StAX based
IO.</li><li>AddressingProperties has been turned from an interface to a
concrete class that can be created directly with "new".
AddressingPropertiesImpl has been removed.</li><li>Many of our
interfaces/classes that held onto constants were either removed or moved. In
particular XmlSchemaConstants was removed (use the Constants from the XmlSchema
library directly), WSDLConstants was moved from api to rt-wsdl, SOAPConstants
was removed (most are available in WSDLConst
ants). Goal is to reduce some memory usage and help startup time and reduce a
lot of duplication.</li><li>AlternativeSelector and the PolicyEngine and other
PolicyRelated classes have been updated to pass the current Message in (when
appropriate) to allow using message contextual information to select the
alternative. HOWEVER, keep in mind that the selected alternative is likely
cached and thus if contextual information changes, the alternative may not be
recalculated.</li><li>FailoverTargetSelector will not activate the fail-over in
cases when HTTP client errors are returned, only HTTP 404 and 503 statuses will
be recognized. Set FailoverTargetSelector supportNotAvailableErrorsOnly
property to false if the support for all HTTP errors is
required.</li><li>ServletController will not override the endpoint addresses by
default as it has side-effects when a given endpoint is accessed via multiple
paths. Set CXFServlet "disable-address-updates" parameter to 'false' if
required.</li><li>T
he long since deprecated org.apache.cxf.frontend.MethodDispatcher has
been removed.  (It was replaced
with org.apache.cxf.service.invoker.MethodDispatcher in 2.6)</li><li>The
deprecated JAXBToStringBuilder and JAXBToStringStyle classes that
were in cxf-rt-databinding-jaxb have been removed.  The functionality has
been provided by cxf-xjc-runtime for a while now.</li><li>The
deprecated URIMappingInterceptor has been removed.  This hasn't been
on the default chain for some time due to a bunch of security related
issues.</li><li>SchemaValidation annotation has had its deprecated "enabled"
property removed. Please use its "type" property to control the
validation.</li><li>The "Spring" type was removed from the FactoryType
annotation.  Instead, use factoryClass=<span style="line-height:
1.4285715;">SpringBeanFactory.class.</span></li></ul></div>
+<div id="ConfluenceContent"><h2
id="id-3.0MigrationGuide-3.0MigrationGuide">3.0 Migration Guide</h2><h4
id="id-3.0MigrationGuide-JAX-RS">JAX-RS</h4><ul><li>JAX-RS 2.0 has been
completely implemented.</li><li>JAX-RS WADL auto-generation code has been moved
to a new cxf-rt-rs-service-description module.</li><li>JAX-RS 2.0 Client API
and CXF specific WebClient and Proxy client code is now available in a new
cxf-rt-rs-client module. Important: the namespace for jaxrs:client elements has
changed from "http://cxf.apache.org/jaxrs"; to
"http://cxf.apache.org/jaxrs-client";</li><li>CXF RequestHandler and
ResponseHandler filters have been removed, please use JAX-RS 2.0
ContainerRequestFilter and ContainerResponseFilter and also WriterInterceptor
and ReaderInterceptor when needed.</li><li>CXF JAX-RS Form extension has been
dropped, please use JAX-RS 2.0 Form.</li><li>CXF JAX-RS ParameterHandler has
been dropped, please use JAX-RS 2.0
ParamConverterProvider.</li><li>javax.annotation.Resource ann
otation can no longer be used to annotate JAX-RS context properties. Only
javax.ws.rs.core.Context annotation is supported from now on.</li></ul><h4
id="id-3.0MigrationGuide-JAX-WS/Soap">JAX-WS/Soap</h4><ul><li>Add new code
generator frontend to add CXF specific constructors and methods. (pass "-fe
cxf" to wsdl2java)</li><li>Make AbstractFeature subclass WebServiceFeature and
update the JAX-WS frontend to look for
them.</li><li>"jaxb-validation-event-handler"s now apply for both Reading and
Writing. (previously only applied to Reading). There are separate
jaxb-(reader|writer)-validation-event-handler properties if you need it set for
only one direction.</li><li>If the WSDL location that is passed into CXF is not
valid, previous versions of CXF *MAY* ignore the error and proceed as if "null"
was passed for the WSDL.   3.0 will now throw an
exception.</li><li>ClientProxy.getClient(proxy) is no longer needed for most
use cases.  The client proxy instances now implement the Cl
ient API directly.   A direct cast to Client should work.</li></ul><h4
id="id-3.0MigrationGuide-Transports">Transports</h4><ul><li>Support for the
older JMS 1.0.2 API's has been removed.   Your JMS provider must support
the 1.1 API's. </li><li>A new WebSocket based transport has been
added</li><li>Support for Netty based HTTP servers and clients has been
added</li></ul><h4 id="id-3.0MigrationGuide-BeanValidation">Bean
Validation</h4><p>Bean Validation 1.1 interceptors and features have been
introduced for JAX-RS and JAX-WS frontends.</p><h4
id="id-3.0MigrationGuide-WS-Security">WS-Security</h4><ul><li>The
DefaultCryptoCoverageChecker now contains boolean properties to easily check if
a WSS UsernameToken was signed and/or encrypted. The default is now that a
UsernameToken must be encrypted.</li><li>CXF 3.0.x picks up a new major version
of Apache WSS4J (2.0.0). There are some changes in this release which will
impact on existing CXF users. These changes are extensively
summarized in the <a shape="rect" class="external-link"
href="http://ws.apache.org/wss4j/migration/wss4j20.html";>WSS4J 2.0.0 Migration
Guide</a>. The major changes are as follows:<br clear="none"><ul><li>If you
have implemented a CallbackHandler to set/retrieve passwords for
UsernameTokens/Signatures/Decryption/etc., then the namespace of the
WSPasswordCallback Object has changed from "org.apache.ws.security" to
"org.apache.wss4j.common.ext".</li><li>If you have implemented a
CallbackHandler to create SAML Assertions, then the namespace of the SAML bean
objects has changed from "org.apache.ws.security.saml.ext" to
"org.apache.wss4j.common.saml". </li><li>WSS4J 1.6.x used a saml
properties file to sign a SAML Assertion. This has been removed in WSS4J 2.0.0.
Instead the SAMLCallback Object contains additional properties that can be set
to sign the Assertion. Please see the section entitled "SAML Assertion changes"
in the <a shape="rect" class="external-link" href="http://ws
.apache.org/wss4j/migration/wss4j20.html">WSS4J 2.0.0 Migration Guide</a> for
more information on this.</li><li>A small number of configuration tags have
been removed in WSS4J 2.0.0. Please see the section entitled "Removed
Configuration Tags in WSS4J 2.0.0" in the <a shape="rect"
class="external-link"
href="http://ws.apache.org/wss4j/migration/wss4j20.html";>WSS4J 2.0.0 Migration
Guide</a> for more information on this.</li><li>The default namespace for
derived keys and secure conversation is now  "<span
class="nolink">http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512</span>".
The older namespace can be used instead via a new configuration
tag.</li><li>The RSA v1.5 Key Transport algorithm is no longer allowed by
default. This can be changed via a configuration tag.</li><li>Turning off BSP
(Basic Security Profile) Compliance (Basic Security Profile) on the outbound
side no longer has the effect of disabling the addition of a
InclusiveNamespaces PrefixList when si
gning a portion of the message. This is now controlled by a separate
configuration tag in WSS4J 2.0.0.</li></ul></li><li>In addition to the changes
above, CXF 3.0.0 fully supports the new streaming (StAX-based) WS-Security
implementation in WSS4J 2.0.0.</li><li>To switch to use the streaming code for
the manual "Action" based approach, simply change the outbound and inbound
interceptors as
follows:<ul><li>"org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor" to
"org.apache.cxf.ws.security.wss4j.WSS4JStaxOutInterceptor".</li><li>"org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor"
to
"org.apache.cxf.ws.security.wss4j.WSS4JStaxInInterceptor".</li></ul></li><li>For
the WS-SecurityPolicy based approach of configuring WS-Security, simply set
the JAX-WS property SecurityConstants.ENABLE_STREAMING_SECURITY
("ws-security.enable.streaming") to "true". For more information on the
streaming functionality available in WSS4J 2.0.0, please see the <a
shape="rect" class="external-link" href="htt
p://ws.apache.org/wss4j/streaming.html">streaming documentation</a> page of
WSS4J.</li></ul><h4
id="id-3.0MigrationGuide-WS-ReliableMessaging">WS-ReliableMessaging</h4><ul><li>The
WS-RM subsystem has been updated to more completely implement the 1.1
specification.  </li><li>Closing a client proxy via
((Closable)proxy).close() will now terminate open sequences.</li></ul><h4
id="id-3.0MigrationGuide-Majordependencychanges">Major dependency
changes</h4><ul><li>Spring 3.2 or newer is required.   The calls to the
API's that were deprecated in Spring 3.x have been removed.  This allows
CXF 3.0 to work with Spring 4, but means it can no longer work with Spring
2.5.</li></ul><h4 id="id-3.0MigrationGuide-CXFModule/JarChanges">CXF Module/Jar
Changes</h4><ul><li>Combined api/core into just a cxf-core. All "wsdl" related
stuff has been moved to a new cxf-wsdl bundle to remove the wsdl4j requirement
for JAX-RS applications.</li><li>Dropped support for Karaf 2.2.x. Karaf 2.3.x
is n
ow required.</li><li>The direct dependency on a javax.mail implementation has
been removed and the CXF maven poms will not pull one in transitively anymore.
For MOST users, this is not a problem. However, if your application uses MTOM
or Soap w/Attachments or similar that requires some of the DataContentHandlers
that are part of the mail implementations, you may need to re-add this to your
classpath.</li><li>DynamicClientFactory was moved from the JAXB databinding to
the Simple frontend. However, users are strongly encouraged to use the
JaxWsDynamicClientFactory subclass.</li><li>The large bundle jar has been
removed due to maintenance issues as well as new functionality not being usable
from the bundle jar.  Users should upgrade to the individual modules that
they need for their application.</li></ul><h4
id="id-3.0MigrationGuide-Removed/ChangedAPI's">Removed/Changed
API's</h4><ul><li>CXFBusImpl has been removed. The only subclass was the
ExtensionManagerBus (SpringBus and Blue
print/osgi stuff subclassed that) so the functionality was pushed up into
ExtensionManagerBus. Some of the "common" methods were put directly on the Bus
interface to make using the Bus cleaner (no casts to the impl).</li><li>The
unused "run()" method on Bus was removed.</li><li>Merge
BaseDataReader/DataReader and the same for the writer, getting rid of the
"Base" versions that are unreferenced.</li><li>The 2 unused params on
Destination.getBackChannel were removed. They were unused and normally passed
in as null.</li><li>Remove QueryHandlers -> these were originally used for
the ?wsdl processing (and is still used for ?js). However, that stuff is better
done directly on the interceptor chains as interceptors to allow user supplied
interceptors to also handle them. I'd like to just remove these. (obviously
update the ?js stuff) Would simplify the CXFServlet a bit.</li><li>Removed all
the /META-INF/cxf/cxf-extension-XYZ.xml files. They have been deprecated and
not needed for a long
time.</li><li>Updated ConduitInitiator and DestinationFactory to pass Bus as
parameter to the various methods.</li><li>Removed support for the old
bus-extensions.xml file (in favor of the current and much faster
bus-extensions.txt)</li><li>Move ALL XML parsing and writing to StaxUtils and
DOM based utilities to DOMUtils. The XMLUtils class that used SAX based parsing
and Transformer based writing has been eliminated. This simplifies the code as
well as increases security as we can provide better limits and have more
control with the StAX based IO.</li><li>AddressingProperties has been turned
from an interface to a concrete class that can be created directly with "new".
AddressingPropertiesImpl has been removed.</li><li>Many of our
interfaces/classes that held onto constants were either removed or moved. In
particular XmlSchemaConstants was removed (use the Constants from the XmlSchema
library directly), WSDLConstants was moved from api to rt-wsdl, SOAPConstants
was removed (most ar
e available in WSDLConstants). Goal is to reduce some memory usage and help
startup time and reduce a lot of duplication.</li><li>AlternativeSelector and
the PolicyEngine and other PolicyRelated classes have been updated to pass the
current Message in (when appropriate) to allow using message contextual
information to select the alternative. HOWEVER, keep in mind that the selected
alternative is likely cached and thus if contextual information changes, the
alternative may not be recalculated.</li><li>FailoverTargetSelector will not
activate the fail-over in cases when HTTP client errors are returned, only HTTP
404 and 503 statuses will be recognized. Set FailoverTargetSelector
supportNotAvailableErrorsOnly property to false if the support for all HTTP
errors is required.</li><li>ServletController will not override the endpoint
addresses by default as it has side-effects when a given endpoint is accessed
via multiple paths. Set CXFServlet "disable-address-updates" parameter to 'false
' if required.</li><li>The long since
deprecated org.apache.cxf.frontend.MethodDispatcher has been removed.
 (It was replaced
with org.apache.cxf.service.invoker.MethodDispatcher in 2.6)</li><li>The
deprecated JAXBToStringBuilder and JAXBToStringStyle classes that
were in cxf-rt-databinding-jaxb have been removed.  The functionality has
been provided by cxf-xjc-runtime for a while now.</li><li>The
deprecated URIMappingInterceptor has been removed.  This hasn't been
on the default chain for some time due to a bunch of security related
issues.</li><li>SchemaValidation annotation has had its deprecated "enabled"
property removed. Please use its "type" property to control the
validation.</li><li>The "Spring" type was removed from the FactoryType
annotation.  Instead, use factoryClass=<span style="line-height:
1.4285715;">SpringBeanFactory.class.</span></li></ul></div>
</div>
<!-- Content -->
</td>
Modified: websites/production/cxf/content/docs/jax-rs-data-bindings.html
==============================================================================
--- websites/production/cxf/content/docs/jax-rs-data-bindings.html (original)
+++ websites/production/cxf/content/docs/jax-rs-data-bindings.html Wed Sep 13
19:57:20 2017
@@ -32,9 +32,9 @@
<link type="text/css" rel="stylesheet"
href="/resources/highlighter/styles/shThemeCXF.css">
<script src='/resources/highlighter/scripts/shCore.js'></script>
-<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
-<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
+<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -122,11 +122,11 @@ Apache CXF -- JAX-RS Data Bindings
 </p><p> </p><p> </p><p> </p><p><style
type="text/css">/*<![CDATA[*/
-div.rbtoc1505314944398 {padding: 0px;}
-div.rbtoc1505314944398 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1505314944398 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1505332602046 {padding: 0px;}
+div.rbtoc1505332602046 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1505332602046 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1505314944398">
+/*]]>*/</style></p><div class="toc-macro rbtoc1505332602046">
<ul class="toc-indentation"><li><a shape="rect"
href="#JAX-RSDataBindings-JAXBsupport">JAXB support</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#JAX-RSDataBindings-ConfiguringJAXBprovider">Configuring JAXB
provider</a></li><li><a shape="rect"
href="#JAX-RSDataBindings-JAXBandMoxy">JAXB and Moxy</a></li></ul>
</li><li><a shape="rect" href="#JAX-RSDataBindings-JSONsupport">JSON
support</a>
@@ -377,7 +377,7 @@ class="org.apache.cxf.jaxrs.provider.JAX
</property>
</bean>
</pre>
-</div></div><ul class="alternate"><li>"inDropElements" list property : can be
used to drop elements during the deserialization; note that children elements
if any of a given dropped element are not affected. Please see the
"outDropElements" property description for an example.</li></ul><ul
class="alternate"><li>"attributesAsElements" boolean property : can be used to
have attributes serialized as elements.</li></ul><p>The combination of
"attributesAsElements" and "outDropElements" properties can be used to have
certain attributes ignored in the output by turning then into elements first
and then blocking them.</p><p>This feature might be used in a number of cases.
For example, one may have rootless JSON array collections such as
"<code>a:b},{c:d</code>" deserialized into a bean by using a "wrapperName"
JSONProvider property with a value like "list" which identifies a bean field
and an "inAppendMap" property with a name of the bean (ex, "book") being
appended before the "list", thus
effectively turning the original JSON sequence into
"{book:{list:<code>a:b},{c:d</code>}}".</p><h1
id="JAX-RSDataBindings-ControllingLargeJAXBXMLandJSONinputpayloads">Controlling
Large JAXB XML and JSON input payloads</h1><p>Starting from CXF 2.6.0 it is
possible to control the depth of large XML and JSON payloads on the
per-endpoint basis in order to limit the risk of the denial of service attacks.
Please see <a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/Security#Security-XML";>this
section</a> on how to use a new DepthRestrictingInterceptor in order to
control XML payloads which are read either by JAXBElementProvider or
SourceProvider (which supports JAXP Source and DOM Document
types).</p><p>Additionally it is possible to configure JAXBElementProvider or
JSONProvider with contextual properties or <a shape="rect"
class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/DocumentDepthProperties.java";
>DocumentDepthProperties</a>:</p><div class="code panel pdl"
>style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><ul class="alternate"><li>"inDropElements" list property : can be
used to drop elements during the deserialization; note that children elements
if any of a given dropped element are not affected. Please see the
"outDropElements" property description for an example.</li></ul><ul
class="alternate"><li>"attributesAsElements" boolean property : can be used to
have attributes serialized as elements.</li></ul><p>The combination of
"attributesAsElements" and "outDropElements" properties can be used to have
certain attributes ignored in the output by turning then into elements first
and then blocking them.</p><p>This feature might be used in a number of cases.
For example, one may have rootless JSON array collections such as
"<code>a:b},{c:d</code>" deserialized into a bean by using a "wrapperName"
JSONProvider property with a value like "list" which identifies a bean field
and an "inAppendMap" property with a name of the bean (ex, "book") being
appended before the "list", thus
effectively turning the original JSON sequence into
"{book:{list:<code>a:b},{c:d</code>}}".</p><h1
id="JAX-RSDataBindings-ControllingLargeJAXBXMLandJSONinputpayloads">Controlling
Large JAXB XML and JSON input payloads</h1><p>Starting from CXF 2.6.0 it is
possible to control the depth of large XML and JSON payloads on the
per-endpoint basis in order to limit the risk of the denial of service attacks.
Please see <a shape="rect" href="securing-cxf-services.html">this section</a>
on how to use a new DepthRestrictingInterceptor in order to control XML
payloads which are read either by JAXBElementProvider or SourceProvider (which
supports JAXP Source and DOM Document types).</p><p>Additionally it is possible
to configure JAXBElementProvider or JSONProvider with contextual properties or
<a shape="rect" class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/staxutils/DocumentDepthProperties.java";>DocumentDepthProperties</a>:</p><div
class="cod
e panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="depthProperties"
class="org.apache.cxf.staxutils.DocumentDepthProperties">
<property name="innerElementCountThreshold" value="500"/>
</bean>
Modified: websites/production/cxf/content/docs/json-support.html
==============================================================================
--- websites/production/cxf/content/docs/json-support.html (original)
+++ websites/production/cxf/content/docs/json-support.html Wed Sep 13 19:57:20
2017
@@ -32,8 +32,8 @@
<link type="text/css" rel="stylesheet"
href="/resources/highlighter/styles/shThemeCXF.css">
<script src='/resources/highlighter/scripts/shCore.js'></script>
-<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
+<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -117,42 +117,18 @@ Apache CXF -- JSON Support
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><h1 id="JSONSupport-JSONOverview">JSON
Overview</h1>
-<p>JSON is a textual data format for data exchange. JSON stands for Javascript
Object Notation and, as the name implies, is itself Javascript. Here is a small
sample:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-{
+<div id="ConfluenceContent"><h1 id="JSONSupport-JSONOverview">JSON
Overview</h1><p>JSON is a textual data format for data exchange. JSON stands
for Javascript Object Notation and, as the name implies, is itself Javascript.
Here is a small sample:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">{
"customer" : {
"name" : "Jane Doe",
"company" : "Acme Enterprises"
}
</pre>
-</div></div>
-
-<p>One of the advantages of JSON is that is very easy for Javascript
developers to use - it simply needs to be evaluated and it immediately becomes
a javascript object. For more information on this see the <a shape="rect"
class="external-link" href="http://json.org"; rel="nofollow">JSON
website</a>.</p>
-
-<p>JSON is supported in CXF through <a shape="rect" class="external-link"
href="http://jettison.codehaus.org"; rel="nofollow">Jettison</a>. Jettison is a
StAX implementation that reads and writes JSON. Jettison intercepts calls to
read/write XML and instead read/writes JSON. </p>
-
-<h1 id="JSONSupport-JSON/XMLConventions">JSON/XML Conventions</h1>
-<p>To understand how to create a JSON service, you first need to understand
how your XML structures will be converted into the JSON format. JSON does not
have many concepts found in XML such as namespaces, attributes or entity
references. Because of this we must adopt <em>conventions</em> on how to
convert between the two.</p>
-
-<p>Jettison supports two conventions currently. These are explained in more
detail in the <a shape="rect" class="external-link"
href="http://jettison.codehaus.org/User%27s+Guide"; rel="nofollow">Jettison
user's guide</a>, but a quick summary of each follows.<br clear="none">
-1. The "mapped" convention. In this convention namespaces are mapped to json
prefixes. For instance, if you have a namespace "http://acme.com"; you could map
it to the "acme" prefix. This means that the element <customer
xmlns="http://acme.com"> would be mapped to the "acme.customer" JSON tag.<br
clear="none">
-2. The <a shape="rect" class="external-link" href="http://badgerfish.ning.com";
rel="nofollow">BadgerFish</a> convention. This convention provides a mapping of
the full XML infoset to JSON. Attributes are represented with an @ sign - i.e.
"@attributeName" : "value". Textual data is represented with the "$" as the
tag. Example:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-{ "customer" : { "name" : { "$" : "Jane Doe" } } }
+</div></div><p>One of the advantages of JSON is that is very easy for
Javascript developers to use - it simply needs to be evaluated and it
immediately becomes a javascript object. For more information on this see the
<a shape="rect" class="external-link" href="http://json.org";
rel="nofollow">JSON website</a>.</p><p>JSON is supported in CXF through <a
shape="rect" class="external-link"
href="https://github.com/jettison-json/jettison"; rel="nofollow">Jettison</a>.
Jettison is a StAX implementation that reads and writes JSON. Jettison
intercepts calls to read/write XML and instead read/writes JSON.</p><h1
id="JSONSupport-JSON/XMLConventions">JSON/XML Conventions</h1><p>To understand
how to create a JSON service, you first need to understand how your XML
structures will be converted into the JSON format. JSON does not have many
concepts found in XML such as namespaces, attributes or entity references.
Because of this we must adopt <em>conventions</em> on how to convert between
the two.<
/p><p>Jettison supports two conventions currently. These are explained in more
detail in the <a shape="rect" class="external-link"
href="http://jettison.codehaus.org/User%27s+Guide"; rel="nofollow">Jettison
user's guide</a>, but a quick summary of each follows.<br clear="none"> 1. The
"mapped" convention. In this convention namespaces are mapped to json prefixes.
For instance, if you have a namespace "http://acme.com"; you could map it to the
"acme" prefix. This means that the element <customer
xmlns="http://acme.com"> would be mapped to the "acme.customer" JSON tag.<br
clear="none"> 2. The <a shape="rect" class="external-link"
href="http://badgerfish.ning.com"; rel="nofollow">BadgerFish</a> convention.
This convention provides a mapping of the full XML infoset to JSON. Attributes
are represented with an @ sign - i.e. "@attributeName" : "value". Textual data
is represented with the "$" as the tag. Example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="code
Content panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">{ "customer" : { "name" : { "$" : "Jane Doe" } } }
</pre>
-</div></div>
-
-<h1 id="JSONSupport-ConfiguringJettison">Configuring Jettison</h1>
-<p>Creating a Jettison service is like creating any other service, except that
you set a couple extra properties on your service's endpoint. First you'll want
to create a service and make sure it is working with XML before continuing
here. Currently its recommended that you use the <a shape="rect"
href="http-binding.html">HTTP Binding</a> for your JSON endpoints as javascript
developers will be more familiar with the RESTful style of interaction. It is
also easier for javascript developers as they will not have to formulate a
request for ever interaction.</p>
-
-<h2 id="JSONSupport-UsingServerFactoryBeans">Using ServerFactoryBeans</h2>
-<p>This example shows how to set up Jettison using a ServerFactoryBean, such
as the JaxWsServerFactoryBean. First you must create a properties HashMap and
set the StAX XMLInputFactory and XMLOutputFactory:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-Map<String,Object> properties = new HashMap<String,Object>();
+</div></div><h1 id="JSONSupport-ConfiguringJettison">Configuring
Jettison</h1><p>Creating a Jettison service is like creating any other service,
except that you set a couple extra properties on your service's endpoint. First
you'll want to create a service and make sure it is working with XML before
continuing here. Currently its recommended that you use the <a shape="rect"
href="http-binding.html">HTTP Binding</a> for your JSON endpoints as javascript
developers will be more familiar with the RESTful style of interaction. It is
also easier for javascript developers as they will not have to formulate a
request for ever interaction.</p><h2
id="JSONSupport-UsingServerFactoryBeans">Using ServerFactoryBeans</h2><p>This
example shows how to set up Jettison using a ServerFactoryBean, such as the
JaxWsServerFactoryBean. First you must create a properties HashMap and set the
StAX XMLInputFactory and XMLOutputFactory:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="code
Content panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">Map<String,Object> properties = new
HashMap<String,Object>();
// Create a mapping between the XML namespaces and the JSON prefixes.
// The JSON prefix can be "" to specify that you don't want any prefix.
@@ -165,20 +141,14 @@ properties.put(XMLInputFactory.class.get
MappedXMLOutputFactory xof = new MappedXMLOutputFactory(nstojns);
properties.put(XMLOutputFactory.class.getName(), xof);
</pre>
-</div></div>
-<p>You must also tell CXF which Content-Type you wish to serve:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-// Tell CXF to use a different Content-Type for the JSON endpoint
+</div></div><p>You must also tell CXF which Content-Type you wish to
serve:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">// Tell CXF to use a different Content-Type for the
JSON endpoint
// This should probably be application/json, but text/plain allows
// us to view easily in a web browser.
properties.put("Content-Type", "text/plain");
</pre>
-</div></div>
-<p>Last, you'll want to actually create your service:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">
-// Build up the server factory bean
+</div></div><p>Last, you'll want to actually create your service:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">// Build up the server factory bean
JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
sf.setServiceClass(CustomerService.class);
// Use the HTTP Binding which understands the Java Rest Annotations
Modified: websites/production/cxf/content/docs/securing-cxf-services.html
==============================================================================
--- websites/production/cxf/content/docs/securing-cxf-services.html (original)
+++ websites/production/cxf/content/docs/securing-cxf-services.html Wed Sep 13
19:57:20 2017
@@ -117,11 +117,11 @@ Apache CXF -- Securing CXF Services
<!-- Content -->
<div class="wiki-content">
<div id="ConfluenceContent"><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1505314840027 {padding: 0px;}
-div.rbtoc1505314840027 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1505314840027 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1505332602424 {padding: 0px;}
+div.rbtoc1505332602424 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1505332602424 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1505314840027">
+/*]]>*/</style></p><div class="toc-macro rbtoc1505332602424">
<ul class="toc-indentation"><li><a shape="rect"
href="#SecuringCXFServices-Securetransports">Secure transports</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#SecuringCXFServices-HTTPS">HTTPS</a></li></ul>
</li><li><a shape="rect"
href="#SecuringCXFServices-SecuringJAX-WSservices">Securing JAX-WS services</a>
@@ -135,8 +135,8 @@ div.rbtoc1505314840027 li {margin-left:
</li><li><a shape="rect"
href="#SecuringCXFServices-Authorization">Authorization</a></li><li><a
shape="rect"
href="#SecuringCXFServices-ControllingLargeRequestPayloads">Controlling Large
Request Payloads</a>
<ul class="toc-indentation"><li><a shape="rect"
href="#SecuringCXFServices-XML">XML</a></li><li><a shape="rect"
href="#SecuringCXFServices-XML-CXFversionspriorto2.7.4">XML - CXF versions
prior to 2.7.4</a></li><li><a shape="rect"
href="#SecuringCXFServices-Multiparts">Multiparts</a></li></ul>
</li><li><a shape="rect"
href="#SecuringCXFServices-Largedatastreamcaching">Large data stream
caching</a></li></ul>
-</div><h1 id="SecuringCXFServices-Securetransports">Secure transports</h1><h2
id="SecuringCXFServices-HTTPS">HTTPS</h2><p>Please see the <a shape="rect"
href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html";>Configuring
SSL Support</a> page for more information.</p><h1
id="SecuringCXFServices-SecuringJAX-WSservices">Securing JAX-WS
services</h1><h2 id="SecuringCXFServices-WS-Security">WS-Security</h2><p>CXF
supports WS-Security via the Apache WSS4J project. WSS4J provides an
implementation of the following WS-Security standards:</p><ul><li><a
shape="rect" class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf";
rel="nofollow"> SOAP Message Security 1.1</a></li><li><a shape="rect"
class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf";
rel="nofollow">Username Token Profile 1.1</a></li><li><a shape="rect"
class="external-link" href="http://docs.oasis-open.org
/wss/v1.1/wss-v1.1-spec-os-x509TokenProfile.pdf" rel="nofollow">X.509
Certificate Token Profile 1.1</a></li><li><a shape="rect" class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf";
rel="nofollow">SAML Token Profile 1.1</a></li><li><a shape="rect"
class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-KerberosTokenProfile.pdf";
rel="nofollow">Kerberos Token Profile 1.1</a></li><li><a shape="rect"
class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SwAProfile.pdf";
rel="nofollow">SOAP Messages with Attachments Profile 1.1</a></li><li><a
shape="rect" class="external-link"
href="http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html";
rel="nofollow">Basic Security Profile 1.1</a></li></ul><p>Please see the <a
shape="rect" href="ws-security.html">WS-Security</a> page for more
information.</p><h2
id="SecuringCXFServices-WS-SecurityPolicy">WS-SecurityPolicy</h2><p>CXF fully
supports WS
-SecurityPolicy, which allows you to configure WS-Security requirements for an
endpoint using a WS-Policy annotation. This is the recommended way of
configuring WS-Security. Policies can be added in a WSDL or else referenced via
an annotation in code.</p><p>The WS-SecurityPolicy layer and the XML-Security
layer in Apache CXF share a common set of security configuration tags from CXF
3.1.0. The <a shape="rect" href="security-configuration.html">Security
Configuration</a> page details these tags and values. There are also some
addition configuration tags, that are only used for when security is configured
via WS-SecurityPolicy, see the following <a shape="rect"
href="ws-securitypolicy.html">page</a> for more information.</p><h2
id="SecuringCXFServices-WS-SecureConversation">WS-SecureConversation</h2><p>CXF
fully supports WS-SecureConveration, see the following <a shape="rect"
href="ws-secureconversation.html">page</a> for more information.</p><h2
id="SecuringCXFServices-WS-Trust,STS">
WS-Trust, STS</h2><p>CXF ships with a advanced SecurityTokenService (STS)
implementation that can be used to issue (SAML) tokens for authentication. CXF
also supports communicating with the STS using the WS-Trust specification. SSO
is supported by caching the tokens on the client side. Please see the <a
shape="rect" class="external-link"
href="https://cwiki.apache.org/CXF20DOC/ws-trust.html";>WS-Trust</a> page for
more information.</p><h1
id="SecuringCXFServices-SecuringJAX-RSservices">Securing JAX-RS
services</h1><h2 id="SecuringCXFServices-JAX-RSXMLSecurity">JAX-RS XML
Security</h2><p>It is possible to secure XML based JAX-RS requests (and
responses) using XML Signature and Encryption. See the <a shape="rect"
href="jax-rs-xml-security.html">JAX-RS XML Security</a> page for more
information.</p><h2 id="SecuringCXFServices-JAX-RSSAML">JAX-RS SAML</h2><p>See
the <a shape="rect" href="jax-rs-saml.html">JAX-RS SAML</a> page on creating
SAML Assertions and adding them to a JAX-RS request
, as well as how to validate them on the receiving side.</p><h2
id="SecuringCXFServices-JAX-RSJOSE">JAX-RS JOSE</h2><p>See the <a shape="rect"
href="jax-rs-jose.html">JAX-RS JOSE</a> page on support for the JWA, JWK, JWS,
JWE and JWT specifications.</p><h1 id="SecuringCXFServices-SSO">SSO</h1><h2
id="SecuringCXFServices-SAMLWebSSO">SAML Web SSO</h2><p>Please see <a
shape="rect" class="external-link"
href="http://coheigea.blogspot.ie/2012/06/saml-web-sso-profile-support-in-apache.html";
rel="nofollow">this blog entry</a> announcing the support for SAML Web SSO
profile and the <a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/SAML+Web+SSO";>SAML
Web SSO</a> page for more information. CXF fully supports the SAML Web SSO
profile on the service provider side. As of yet however, no IdP is available in
CXF.</p><h2 id="SecuringCXFServices-WS-Federation">WS-Federation</h2><p>Apache
CXF <a shape="rect" href="../fediz.html">Fediz</a> is a subproject of CXF.
Fediz helps y
ou to secure your web applications and delegates security enforcement to the
underlying application server. With Fediz, authentication is externalized from
your web application to an identity provider installed as a dedicated server
component. The supported standard is <a shape="rect" class="external-link"
href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175002";
rel="nofollow">WS-Federation Passive Requestor Profile</a>. Fediz supports <a
shape="rect" class="external-link"
href="http://en.wikipedia.org/wiki/Claims-based_identity"; rel="nofollow">Claims
Based Access Control</a> beyond Role Based Access Control (RBAC).</p><h1
id="SecuringCXFServices-OAuth">OAuth</h1><p>Please check <a shape="rect"
href="http://cxf.apache.org/docs/jax-rs-oauth2.html";>OAuth2.0</a> and <a
shape="rect" href="http://cxf.apache.org/docs/jax-rs-oauth.html";>OAuth1.0</a>
pages for the information about the support for OAuth 2.0 and OAuth 1.0 in
CXF.</p><h1 id="Secu
ringCXFServices-Authentication">Authentication</h1><h2
id="SecuringCXFServices-JAASLoginInterceptor">JAASLoginInterceptor</h2><p>Container
or Spring Security managed authentication as well as the custom authentication
are all the viable options used by CXF developers.</p><p>Starting from CXF
2.3.2 and 2.4.0 it is possible to use an
org.apache.cxf.interceptor.security.JAASLoginInterceptor in order to
authenticate a current user and populate a CXF SecurityContext.</p><p>Example
:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><jaxws:endpoint address="/soapService">
+</div><h1 id="SecuringCXFServices-Securetransports">Secure transports</h1><h2
id="SecuringCXFServices-HTTPS">HTTPS</h2><p>Please see the <a shape="rect"
href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html";>Configuring
SSL Support</a> page for more information.</p><h1
id="SecuringCXFServices-SecuringJAX-WSservices">Securing JAX-WS
services</h1><h2 id="SecuringCXFServices-WS-Security">WS-Security</h2><p>CXF
supports WS-Security via the Apache WSS4J project. WSS4J provides an
implementation of the following WS-Security standards:</p><ul><li><a
shape="rect" class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SOAPMessageSecurity.pdf";
rel="nofollow"> SOAP Message Security 1.1</a></li><li><a shape="rect"
class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf";
rel="nofollow">Username Token Profile 1.1</a></li><li><a shape="rect"
class="external-link" href="http://docs.oasis-open.org
/wss/v1.1/wss-v1.1-spec-os-x509TokenProfile.pdf" rel="nofollow">X.509
Certificate Token Profile 1.1</a></li><li><a shape="rect" class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SAMLTokenProfile.pdf";
rel="nofollow">SAML Token Profile 1.1</a></li><li><a shape="rect"
class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-KerberosTokenProfile.pdf";
rel="nofollow">Kerberos Token Profile 1.1</a></li><li><a shape="rect"
class="external-link"
href="http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-SwAProfile.pdf";
rel="nofollow">SOAP Messages with Attachments Profile 1.1</a></li><li><a
shape="rect" class="external-link"
href="http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html";
rel="nofollow">Basic Security Profile 1.1</a></li></ul><p>Please see the <a
shape="rect" href="ws-security.html">WS-Security</a> page for more
information.</p><h2
id="SecuringCXFServices-WS-SecurityPolicy">WS-SecurityPolicy</h2><p>CXF fully
supports WS
-SecurityPolicy, which allows you to configure WS-Security requirements for an
endpoint using a WS-Policy annotation. This is the recommended way of
configuring WS-Security. Policies can be added in a WSDL or else referenced via
an annotation in code.</p><p>The WS-SecurityPolicy layer and the XML-Security
layer in Apache CXF share a common set of security configuration tags from CXF
3.1.0. The <a shape="rect" href="security-configuration.html">Security
Configuration</a> page details these tags and values. There are also some
addition configuration tags, that are only used for when security is configured
via WS-SecurityPolicy, see the following <a shape="rect"
href="ws-securitypolicy.html">page</a> for more information.</p><h2
id="SecuringCXFServices-WS-SecureConversation">WS-SecureConversation</h2><p>CXF
fully supports WS-SecureConveration, see the following <a shape="rect"
href="ws-secureconversation.html">page</a> for more information.</p><h2
id="SecuringCXFServices-WS-Trust,STS">
WS-Trust, STS</h2><p>CXF ships with a advanced SecurityTokenService (STS)
implementation that can be used to issue (SAML) tokens for authentication. CXF
also supports communicating with the STS using the WS-Trust specification. SSO
is supported by caching the tokens on the client side. Please see the <a
shape="rect" href="ws-trust.html">WS-Trust</a> page for more
information.</p><h1 id="SecuringCXFServices-SecuringJAX-RSservices">Securing
JAX-RS services</h1><h2 id="SecuringCXFServices-JAX-RSXMLSecurity">JAX-RS XML
Security</h2><p>It is possible to secure XML based JAX-RS requests (and
responses) using XML Signature and Encryption. See the <a shape="rect"
href="jax-rs-xml-security.html">JAX-RS XML Security</a> page for more
information.</p><h2 id="SecuringCXFServices-JAX-RSSAML">JAX-RS SAML</h2><p>See
the <a shape="rect" href="jax-rs-saml.html">JAX-RS SAML</a> page on creating
SAML Assertions and adding them to a JAX-RS request, as well as how to validate
them on the receiving side.
</p><h2 id="SecuringCXFServices-JAX-RSJOSE">JAX-RS JOSE</h2><p>See the <a
shape="rect" href="jax-rs-jose.html">JAX-RS JOSE</a> page on support for the
JWA, JWK, JWS, JWE and JWT specifications.</p><h1
id="SecuringCXFServices-SSO">SSO</h1><h2
id="SecuringCXFServices-SAMLWebSSO">SAML Web SSO</h2><p>Please see <a
shape="rect" class="external-link"
href="http://coheigea.blogspot.ie/2012/06/saml-web-sso-profile-support-in-apache.html";
rel="nofollow">this blog entry</a> announcing the support for SAML Web SSO
profile and the <a shape="rect"
href="https://cwiki.apache.org/confluence/display/CXF20DOC/SAML+Web+SSO";>SAML
Web SSO</a> page for more information. CXF fully supports the SAML Web SSO
profile on the service provider side. As of yet however, no IdP is available in
CXF.</p><h2 id="SecuringCXFServices-WS-Federation">WS-Federation</h2><p>Apache
CXF <a shape="rect" href="../fediz.html">Fediz</a> is a subproject of CXF.
Fediz helps you to secure your web applications and delegates securit
y enforcement to the underlying application server. With Fediz, authentication
is externalized from your web application to an identity provider installed as
a dedicated server component. The supported standard is <a shape="rect"
class="external-link"
href="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175002";
rel="nofollow">WS-Federation Passive Requestor Profile</a>. Fediz supports <a
shape="rect" class="external-link"
href="http://en.wikipedia.org/wiki/Claims-based_identity"; rel="nofollow">Claims
Based Access Control</a> beyond Role Based Access Control (RBAC).</p><h1
id="SecuringCXFServices-OAuth">OAuth</h1><p>Please check <a shape="rect"
href="http://cxf.apache.org/docs/jax-rs-oauth2.html";>OAuth2.0</a> and <a
shape="rect" href="http://cxf.apache.org/docs/jax-rs-oauth.html";>OAuth1.0</a>
pages for the information about the support for OAuth 2.0 and OAuth 1.0 in
CXF.</p><h1 id="SecuringCXFServices-Authentication">Authentication</h1><h2 i
d="SecuringCXFServices-JAASLoginInterceptor">JAASLoginInterceptor</h2><p>Container
or Spring Security managed authentication as well as the custom authentication
are all the viable options used by CXF developers.</p><p>Starting from CXF
2.3.2 and 2.4.0 it is possible to use an
org.apache.cxf.interceptor.security.JAASLoginInterceptor in order to
authenticate a current user and populate a CXF SecurityContext.</p><p>Example
:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><jaxws:endpoint address="/soapService">
<jaxws:inInterceptors>
<ref bean="authenticationInterceptor"/>
</jaxws:inInterceptors>
@@ -154,7 +154,7 @@ div.rbtoc1505314840027 li {margin-left:
-->
</pre>
</div></div><p>The JAAS authenticator is configured with the name of the JAAS
login context (the one usually specified in the JAAS configuration resource
which the server is aware of). It is also configured with an optional
"roleClassifier" property which is needed by the CXF SecurityContext in order
to differentiate between user and role Principals. By default CXF will assume
that role Principals are represented by javax.security.acl.Group
instances.</p><p>In some cases objects representing a user principal and roles
are implementing the same marker interface such as Principal. That can be
handled like this:</p><div class="code panel pdl" style="border-width:
1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="authenticationInterceptor"
class="org.apache.cxf.interceptor.security.JAASLoginInterceptor">
+<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><bean id="authenticationInterceptor"
class="org.apache.cxf.interceptor.security.JAASLoginInterceptor">
<property name="contextName" value="jaasContext"/>
<property name="roleClassifier" value="RolePrincipal"/>
<property name="roleClassifierType" value="classname"/>
@@ -162,7 +162,7 @@ div.rbtoc1505314840027 li {margin-left:
<!-- Similarly for JAX-RS endpoints -->
</pre>
</div></div><p>In this case JAASLoginInterceptor will know that the roles are
represented by a class whose simple name is RolePrincipal. Note that full class
names are also supported.</p><h2
id="SecuringCXFServices-Kerberos">Kerberos</h2><p>Please see <a shape="rect"
href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerberos%29";>this
page</a> for the information about Spnego/Kerberos HTTPConduit client
support.</p><p>Please check the following blog entries about WS-Security
Kerberos support in CXF:</p><p><a shape="rect" class="external-link"
href="http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part-i.html";
rel="nofollow">Using Kerberos with Web Services - part 1</a><br clear="none">
<a shape="rect" class="external-link"
href="http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part.html";
rel="nofollow">Using Kerberos with Web Services - part 2<
/a><br clear="none"> <a shape="rect" class="external-link"
href="http://coheigea.blogspot.com/2012/02/ws-trust-spnego-support-in-apache-cxf.html";
rel="nofollow">WS-Trust SPNego support in Apache CXF </a></p><p>Please check
the following <a shape="rect" href="jaxrs-kerberos.html">page</a> about
Kerberos support in JAX-RS.</p><h1
id="SecuringCXFServices-Authorization">Authorization</h1><p>Container or Spring
Security managed authorization as well as the custom authorization are all the
viable options used by CXF developers.</p><p>CXF 2.3.2 and 2.4.0 introduce
org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor and
org.apache.cxf.interceptor.security.SecureAnnotationsInterceptor interceptors
which can help with enforcing the authorization rules.</p><p>Example :</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><jaxws:endpoint id="endpoint1"
address="/soapService1">
+<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><jaxws:endpoint id="endpoint1"
address="/soapService1">
<jaxws:inInterceptors>
<ref bean="authorizationInterceptor"/>
</jaxws:inInterceptors>
@@ -195,7 +195,7 @@ div.rbtoc1505314840027 li {margin-left:
</pre>
</div></div><h1
id="SecuringCXFServices-ControllingLargeRequestPayloads">Controlling Large
Request Payloads</h1><h2 id="SecuringCXFServices-XML">XML</h2><p>Starting with
CXF 2.7.4, CXF now requires use of a StAX parser that can provide fine grained
control over the size of the incoming XML. The only parser that will currently
work is Woodstox 4.2 or newer. The main reason is there are a series of DOS
attacks that can only be prevented at the StAX parser level. There is a
"org.apache.cxf.stax.allowInsecureParser" System Property that can be set to
true to allow using an insecure parser, but that is HIGHLY not recommended and
doing so would also now allow the settings described in this section.</p><p>CXF
has several default settings that will prevent malicious XML from causing
various DOS failures. You can override the default values if you know you will
have incoming XML that will exceed these limits. These settings can be set as
Bus level properties, endpoint level properties, or ev
en per request via an interceptor.</p><div class="table-wrap"><table
class="confluenceTable"><tbody><tr><th colspan="1" rowspan="1"
class="confluenceTh"><p>Setting</p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p>Default</p></th><th colspan="1" rowspan="1"
class="confluenceTh"><p>Description</p></th></tr><tr><td colspan="1"
rowspan="1"
class="confluenceTd"><p>org.apache.cxf.stax.maxChildElements</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>50000</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Maximum number of child elements for a
given parent element</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>org.apache.cxf.stax.maxElementDepth</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>100</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Maximum depth of an
element</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>org.apache.cxf.stax.maxAttributeCount</p></td><td
colspan="1" rowspan="1" c
lass="confluenceTd"><p>500</p></td><td colspan="1" rowspan="1"
class="confluenceTd"><p>Maximum number of attributes on a single
element</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>org.apache.cxf.stax.maxAttributeSize</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>64K</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Maximum size of a single
attribute</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>org.apache.cxf.stax.maxTextLength</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>128M</p></td><td colspan="1"
rowspan="1" class="confluenceTd"><p>Maximum size of an elements text
value</p></td></tr><tr><td colspan="1" rowspan="1"
class="confluenceTd"><p>org.apache.cxf.stax.maxElementCount</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Long.MAX_VALUE</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Maximum total number of
elements in the XML document</p></td></tr><tr><td colspan="1" row
span="1"
class="confluenceTd"><p>org.apache.cxf.stax.maxXMLCharacters</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Long.MAX_VALUE</p></td><td
colspan="1" rowspan="1" class="confluenceTd"><p>Maximum total number of
characters parsed by the parser</p></td></tr></tbody></table></div><h2
id="SecuringCXFServices-XML-CXFversionspriorto2.7.4">XML - CXF versions prior
to 2.7.4</h2><p>Endpoints expecting XML payloads may get <a shape="rect"
class="external-link"
href="http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/DepthRestrictingStreamInterceptor.java";>DepthRestrictingInterceptor</a>
registered and configured in order to control the limits a given XML payload
may not exceed. This can be useful in a variety of cases in order to protect
against massive payloads which can potentially cause the denial-of-service
situation or simply slow the service down a lot.</p><p>The complete number of
XML elements, the number of immediate c
hildren of a given XML element may contain and the stack depth of the payload
can be restricted, for example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="depthInterceptor"
class="org.apache.cxf.interceptor.security.DepthRestrictingStreamInterceptor">
+<pre class="brush: xml; gutter: false; theme: Default"
style="font-size:12px;"><bean id="depthInterceptor"
class="org.apache.cxf.interceptor.security.DepthRestrictingStreamInterceptor">
<!-- Total number of elements in the XML payload -->
<property name="elementCountThreshold" value="5000"/>
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 Sep 13 19:57:20
2017
@@ -32,9 +32,9 @@
<link type="text/css" rel="stylesheet"
href="/resources/highlighter/styles/shThemeCXF.css">
<script src='/resources/highlighter/scripts/shCore.js'></script>
-<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
-<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
+<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -118,7 +118,7 @@ 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><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">
<span class="confluence-embedded-file-wrapper"><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";></span></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 mes
sage as she is the only one with the private key.<br clear="none"> <span
class="confluence-embedded-file-wrapper"><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";></span></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">
<span class="confluence-embedded-file-wrapper"><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_sig
ning.svg.png"
data-image-src="http://upload.wikimedia.org/wikipedia/commons/thumb/1/1e/Public_key_signing.svg/280px-Public_key_signing.svg.png";></span></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">
+<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/wss4j20.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=
"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"> <span class="confluence-embedded-file-wrapper"><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";></span></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">
<span class="confluence-embedded-file-wrapper"><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";></span></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">
<span class="confluence-embedded-file-wrapper"><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";></span></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">
<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">import org.apache.cxf.endpoint.Endpoint;
import org.apache.cxf.jaxws.EndpointImpl;
![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}
