Securing CXF Services

Secure transports

HTTPS

Please see the Configuring SSL Support page for more information.

Security Configuration

The WS-Security 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 configuration tags that are only used for when security is configured via WS-SecurityPolicy, see the following page for more information.

WS-* Security (including UsernameToken and X.509 Token profiles)

Please see the WS-* Support page for more information.

WS-Trust, STS

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

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.

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.

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 :

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.

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:

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 blog entries about WS-Security Kerberos support in CXF:

Using Kerberos with Web Services - part 1
Using Kerberos with Web Services - part 2
WS-Trust SPNego support in Apache CXF

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.

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 :

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.

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.

Setting

Default

Description

org.apache.cxf.stax.maxChildElements

50000

Maximum number of child elements for a given parent element

org.apache.cxf.stax.maxElementDepth

100

Maximum depth of an element

org.apache.cxf.stax.maxAttributeCount

500

Maximum number of attributes on a single element

org.apache.cxf.stax.maxAttributeSize

64K

Maximum size of a single attribute

org.apache.cxf.stax.maxTextLength

128M

Maximum size of an elements text value

org.apache.cxf.stax.maxElementCount

Long.MAX_VALUE

Maximum total number of elements in the XML document

org.apache.cxf.stax.maxXMLCharacters

Long.MAX_VALUE

Maximum total number of characters parsed by the parser

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.

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:

When one of the limits is reached, the error is returned. JAX-WS consumers will receive 500, JAX-RS/HTTP consumers: 413.

The following system properties can also be set up for JAX-WS endpoints: "org.apache.cxf.staxutils.innerElementCountThreshold" and "org.apache.cxf.staxutils.innerElementLevelThreshold".

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.

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

Property Name

Value

org.apache.cxf.io.CachedOutputStream.Threshold

The threshold value in bytes to switch from memory to file caching

org.apache.cxf.io.CachedOutputStream.MaxSize

The data size in bytes to limit the maximum data size to be cached

org.apache.cxf.io.CachedOutputStream.OutputDirectory

The directory name for storing the temporary files

org.apache.cxf.io.CachedOutputStream.CipherTransformation

The cipher transformation name for encryptiing the cached content

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

The encryption option, which is available from CXF 2.6.4 and 2.7.1, uses a symmetric encryption using a generated key and it can be used to protect the cached content from unauthorized access. To enable encryption, the CipherTransformation property can be set to the name of an appropriate stream or 8-bit block cipher transformation (e.g., RC4, AES/CTR/NoPadding, etc) that is supported by the environment. However, it is noted that enabling the encryption will result in an increased processing time and it is therefore recommended only in specific use cases where other means to protect the cached content is unavailable.