Securing CXF Services

Secure transports

HTTPS

Please see the Configuring SSL Support page for more information.

Securing JAX-WS services

WS-Security

CXF supports WS-Security via the Apache WSS4J project. WSS4J provides an implementation of the following WS-Security standards:

• SOAP Message Security 1.1
• Username Token Profile 1.1
• X.509 Certificate Token Profile 1.1
• SAML Token Profile 1.1
• Kerberos Token Profile 1.1
• SOAP Messages with Attachments Profile 1.1
• Basic Security Profile 1.1

Please see the WS-Security page for more information.

...

WS-SecurityPolicy

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.

The WS-Security SecurityPolicy layer and the XML-Security layer in Apache CXF share a common set of security configuration tags from CXF 3.1.0. The Security Configuration page details these tags and values. The WS-Security layer also has some additional There are also some addition configuration tags, that are only used for when security is configured via WS-SecurityPolicy, see the following page for more information.

WS-

...

SecureConversation

CXF fully supports WS-SecureConveration, see the following Please see the WS-* Support page for more information.

WS-Trust, STS

Please see 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 page for more information.

SAML Web SSO

Please see this blog entry announcing the support for SAML Web SSO profile and the SAML Web SSO specification. SSO is supported by caching the tokens on the client side. Please see the WS-Trust page for more information.

Securing JAX-RS services

JAX-RS XML Security

It is possible to secure XML based JAX-RS requests (and responses) using XML Signature and Encryption. See the JAX-RS XML Security page for more information.

JAX-RS SAML

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.

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.

WS-Federation

Apache CXF Fediz is a subproject of CXF. Fediz helps you 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 WS-Federation Passive Requestor Profile. Fediz supports Claims Based Access Control beyond Role Based Access Control (RBAC).

OAuth

Please check OAuth2.0 and OAuth1.0 pages for the information about the support for OAuth 2.0 and OAuth 1.0 in CXF.

Authentication

JAASLoginInterceptor

Container or Spring Security managed authentication as well as the custom authentication are all the viable options used by CXF developers.

...

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.

Kerberos

Please see this page for the information about Spnego/Kerberos HTTPConduit client support.

...

Please check the following page about Kerberos support in JAX-RS.

Authorization

Container or Spring Security managed authorization as well as the custom authorization are all the viable options used by CXF developers.

...

<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>

Controlling Large Request Payloads

XML

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.

...

XML - CXF versions prior to 2.7.4

Endpoints expecting XML payloads may get DepthRestrictingInterceptor 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.

...

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

Multiparts

The "org.apache.cxf.io.CachedOutputStream.MaxSize" system property or "attachment-max-size" per-endpoint contextual property can be used to control the size of large attachments. When the limits is reached, the error is returned. JAX-WS consumers will receive 500, JAX-RS/HTTP consumers: 413.

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 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.

...