...

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 WS-Trust page for more information.

...

See the JAX-RS SAML page on creating SAML Assertions and adding them to a JAX-RS request, as well as how to validate them on the receiving side.

JAX-RS JOSE

See the JAX-RS JOSE page on support for the JWA, JWK, JWS, JWE and JWT specifications.

HTTP Signature

See the JAX-RS HTTP Signature page on support for the HTTP Signature specification.

SSO

SAML Web SSO

Please see this blog entry announcing the support for SAML Web SSO profile and the SAML Web SSO 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.

...

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.

Example :

<jaxws:endpoint address="/soapService">
 <jaxws:inInterceptors>
   <ref bean="authenticationInterceptor"/>
 </jaxws:inInterceptors>
</jaxws:endpoint>

<bean id="authenticationInterceptor" class="org.apache.cxf.interceptor.security.JAASLoginInterceptor">
   <property name="contextName" value="jaasContext"/>
   <property name="roleClassifier" value="ROLE_"/>

</bean>
<!--
  Similarly for JAX-RS endpoints.
  Note that org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
  can be registered as jaxrs:provider instead
-->

...

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:

<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"/>
</bean>
<!-- Similarly for JAX-RS endpoints -->

...

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.

Example :

<jaxws:endpoint id="endpoint1" address="/soapService1">
 <jaxws:inInterceptors>
   <ref bean="authorizationInterceptor"/>
 </jaxws:inInterceptors>
</jaxws:endpoint>

<bean id="authorizationInterceptor" class="org.apache.cxf.interceptor.security.SimpleAuthorizingInterceptor">
   <property name="methodRolesMap">
      <map>
        <!-- no wildcard support, names need to match exactly -->
        <entry key="addNumbers" value="ROLE_USER ROLE_ADMIN"/>
        <entry key="divideNumbers" value="ROLE_ADMIN"/>
      </map>
   </property>
   <!-- its possible to define global roles that apply to all WSDL operations not listed above -->
   <property name="globalRoles" value="ROLE_ADMIN"/>
</bean>

<jaxws:endpoint id="endpoint2" address="/soapService2" implementor="#secureBean">
 <jaxws:inInterceptors>
   <ref bean="authorizationInterceptor2"/>
 </jaxws:inInterceptors>
</jaxws:endpoint>

<!-- This bean is annotated with secure annotations such as RolesAllowed -->
<bean id="secureBean" class="org.apache.cxf.tests.security.SecureService"/>

<bean id="authorizationInterceptor2" class="org.apache.cxf.interceptor.security.SecureAnnotationsInterceptor">
   <property name="securedObject" ref="secureBean"/>
</bean>

...

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 even per request via an interceptor.

XML - CXF versions prior to 2.7.4

...

The complete number of XML elements, the number of immediate children of a given XML element may contain and the stack depth of the payload can be restricted, for example:

<bean id="depthInterceptor" class="org.apache.cxf.interceptor.security.DepthRestrictingStreamInterceptor">
  <!-- Total number of elements in the XML payload -->
  <property name="elementCountThreshold" value="5000"/>

  <!-- Total number of child elements for XML elements -->
  <property name="innerElementCountThreshold" value="3000"/>

  <!-- Maximum stack depth of the XML payload -->
  <property name="innerElementLevelThreshold" value="20"/>

</bean>

<jaxws:endpoint>
  <jaxws:inInterceptors>
   <ref bean="depthInterceptor"/>
 </jaxws:inInterceptors>
<jaxws:endpoint>

<jaxrs:server>
  <jaxrs:inInterceptors>
   <ref bean="depthInterceptor"/>
 </jaxrs:inInterceptors>
<jaxrs:server>

...

Please check this section for the additional information on how JAX-RS JAXB-based providers can be configured.

Multiparts

...

It's possible to control various properties associated with caching large attachments via the following per-endpoint contextual properties:

If no per-endpoint contextual properties are specified, then CXF checks any values that are set for the corresponding System properties listed below for large data stream caching and re-uses them for caching attachments.

Large data stream caching

A large stream based message or data will be cached in a temporary file. In default, this caching occurs at data size larger than 64K bytes and a temporary file , which is written in the system's temporary directory. You can change this behavior and other properties of the caching feature by explicitly setting the following properties.

To change the default behavior for the entire system, you can set the following system properties.

To change the default behavior for a specific bus, you can set the corresponding bus.io.CachedOutputStream properties (e.g., bus.io.CachedOutputStream.Threshold for org.apache.cxf.io.CachedOutputStream.Threshold).

...