Child pages
  • JAX-RS XML Security
Skip to end of metadata
Go to start of metadata



 JAX-RS: XML Security 





CXF 2.5.0 introduces an initial support for securing JAX-RS clients and endpoints with XML Signature and XML Encryption.
This is a work in progress and the enhancements will be applied regularly. Support for the alternative signature and encryption technologies will also be provided in due time.

Maven dependencies

Backwards compatibility configuration note

From Apache CXF 3.1.0, the WS-Security based configuration tags used to configure XML Signature or Encryption ("ws-security-*") have been changed to just start with "security-". Apart from this they are exactly the same. Older "ws-security-" values continue to be accepted in CXF 3.1.0. To use any of the configuration examples in this page with an older version of CXF, simply add a "ws-" prefix to the configuration tag.

XML Signature

XML Signature defines 3 types of signatures: enveloped, enveloping and detached. All the three types are supported by CXF JAX-RS.

New Starting from CXF 2.5.2 it is also possible to add XML Signatures on the server side and get them validated on the client side.

Enveloped signatures


Note that the Book root element is signed including its name and id children, and a signature ds:Reference links to Book.

Server Configuration fragment:

Note that is responsible for validating the signature attached to the inbound payload and is capable of processing all 3 types of XML Signature. is responsible for adding a new signature to the outbound payload.

Client code:

Spring configuration can also be used.
Please also check Secure JAX-RS Services on how HTTPS can be configured from Spring.

Enveloping signatures


This time the signature is enveloping the Book element using a ds:Object wrapper which ds:Reference links to.

Server Configuration fragment is identical to the one shown in the Enveloped signatures section.

Client code is nearly identical to the one shown in the Enveloped signatures section except that XmlSigOutInterceptor need to have an additional property set:

Detached signatures


Note that the whole payload is enveloped by a configurable element wrapper. The Book instance is one part of the envelope and it's signed by a detached signature (see the first ds:Signature, with its ds:Reference linking to Book). The envelope also has an embedded SAML assertion which has its own enveloped signature.

The instance of will handle a detached XML signature of the Book XML fragment on the server side. See the JAX-RS SAML for more info on how to deal with SAML assertions.

Client code is nearly identical to the one shown in the Enveloped signatures section except that XmlSigOutInterceptor need to have an additional property set:

Customizing the signature manages the creation of the signature on the client side.
The following properties can be set on it at the moment:

"style": possible values are "enveloped" (default), "enveloping" and "detached"
"envelopedName": only used with the "detached" style, default is "{http://org.apache.cxf/rs/env}Envelope"
"signatureAlgorithm": default is ""
"digestAlgorithm": default is ""

Signature Key Info Validation

By default ds:Signature is expected to contain ds:KeyInfo element.

Setting a "keyInfoMustBeAvailable" property to false on the out interceptors will lead to KeyInfo not included.

If the same property is set to false on the in interceptors then either an authenticated Principal name or a default store alias will be used to load the certificate for validating the signature.

XML Encryption

Encrypting XML payloads makes it possible to drop a requirement for HTTPS.

Here is a payload example:

Here is a server configuration fragment:

This configuration supports receiving signed and then encrypted XML payloads.

The code:

Note that XmlEncOutInterceptor interceptor has a "symmetricEncAlgorithm" property set to a weaker type just to get CXF tests passing.

The actual application client code does not expect a payload such as Book back but if it did then configuring the server to encrypt the response would be straightforward:

Now the client code can be updated to expect an encrypted and signed Book back:

Using the request signature certificates for the encryption

From CXF 2.6.1 and 2.5.4:

When multiple clients are posting the encrypted and signed payloads, the following configuration will lead to the request signature certificates being utilized for encrypting the symmetric key used to encrypt the response:

The "security.encryption.username" server property is set to "useReqSigCert".

Note that the client configuration assumes Alice (with its represents a given client, Bob (with its - the receiver/server.

On the server side the encryption properties point to and to This is because the outbound signature needs to be done with the Bob's certificate and the encryption - with either the specific Alice's certificate or the certificate from the inbound signature. Note that the in encryption handler will check the signature properties first - this will ensure that the Bob's certificate used to encrypt the data on the client side can be validated, similarly for the in signature handler.

Customizing the encryption manages the encryption process.
The following properties can be set on it at the moment:
"symmetricEncAlgorithm": default is "", complete URIs or short identifiers are supported, for example, "aes128-cbc" or "".
"digestAlgorithm": optional, example "" can be set.
"keyEncAlgorithm": default is ""
"keyIdentifierType": default is "X509_KEY", "X509_ISSUER_SERIAL" is also supported - useful when the whole x509Certificate should not be embedded

GCM Algorithm and BouncyCastle provider

Please see Colm's blog for the information about the possible attack against XML Encryption and the GCM algorithm which needs to be used in order to prevent it.

Restricting encryption and signature algorithms

From CXF 2.6.1 and 2.5.4:

It is possible to configure the in encryption and signature handlers with the properties restricting the encryption and signature algorithms that clients can use, for example:

Getting the same SignatureProperties and EncryptionProperties beans (with "sigProps" and "encProps" ids) registered with the outbound
handlers will ensure that the algorithms used by the current client have not only been validated on the inbound side but also used on the outbound side for encrypting and signing the data.

Note that from CXF 2.7.1, 2.6.4 and 2.5.7, the XmlEncInHandler will require that the RSA-OAEP algorithm be used as the key transport encryption algorithm by default. As this algorithm is used by default by the XmlEncOutInterceptor, no action is required unless you are specifying a different algorithm on the outbound side. In this case, an EncryptionProperties object will need to be configured on XmlEncInHandler with the desired key transport algorithm.


The payloads containing the enveloping XML Signatures are structured according to the XML Signature specification and as such can be consumed by any XML Signature aware consumers capable of handling the enveloping signatures and extracting the signed payload.

Same applies to enveloped signatures, for example, a signed SAML assertion always contains an enveloped signature.

The way CXF creates detached XML Signatures is experimental, so at the moment CXF will be required on both ends for the detached signatures be created and validated.

The current XML Encryption support is in line with the specification and thus the capable non-CXF consumers will be able to decrypt the payloads.

  • No labels