Simple XML Security with CXF JAX-RS

Enhancing the security support for JAX-RS services was a major theme during the CXF 2.5.0 development. CXF already offers a good support for users to create secure RESTful services relying on HTTPS and it also offers a number of useful utility classes for enforcing the authentication and authorization rules.

But the security can be a much richer subject, it is indeed and it is the right time now for us to start working on the advanced security features for CXF JAX-RS users to start experimenting and working with the message level security, tapping into the richness of SAML, deploying OAuth solutions. And we will be analyzing and providing a support for the most interesting and useful security features which are already being or will be used by the community.

As far as the message level security is concerned, XML Signature and XML Encryption are the two prominent W3C specifications which have been used as the basis for providing the message integrity and confidentiality without relying on HTTPS mainly for SOAP XML services, with the help of WS-Security related specifications.

In REST, XML is only one of the many formats which can be supported, but XML is still a very major format which is used a lot. Given the popularity of XML and also to simplify the integration with SOAP-based solutions, it does make sense to get the message-level security supported well for XML services and get to supporting other relevant efforts allowing to sign all sort of payloads next.

And this is what we did in CXF 2.5.0. We put a lot of effort in providing a solution that will make working with XML Security a child's play yet practical and able to deliver for users relying on JAX-RS.

XML Signature and XML Encryption are complex specifications but I hope you can agree after reading this section that working with these specifications and making them protect the messages can be interesting, simple and a real fun.

Note that all what is needed to get an XML signature applied to a given application payload is to register a single handler on client and server sides. By default, a signature will be enveloped as a last child inside a given XML instance such as Book. On the server side, the signature will be validated, removed from the payload and made available on the current Message for other handlers to use it if needed, for example, for optional SAML handlers be able to verify SubjectConfirmation methods such as "sender-vouches".

After the payload has become 'free' of its enclosed signature, it's wrapped in a useful CXF DOM-aware STAX reader and passed along to the JAX-RS runtime.

Making CXF JAX-RS produce enveloping or detached signatures is as easy as setting a signature style property on a client-side handler with the server side one capable of reading all types of signatures.

And now that we have a signed payload, isn't it tempting to get it encrypted too ? So here you go, all you need to get a self-contained EncryptedData with an embedded EncryptedKey capturing an encryption key is to register a single handler on client and server sides which will help CXF encrypt a payload (possibly signed) and then decrypt it on the server side.

One thing which is worth noting is that WSS4J is relied upon by this feature - this is an internal implementation detail and should be of no concern to users building advanced secure RESTful services. WSS4J has a lot of useful code and it makes sense at this stage to reuse it under the hood.

Give it a try please and as usual, please help us with the feedback. If you are a security expert - let us know what may need to be improved and if you are not - learn new advanced security concepts with CXF and become the one :-) Enjoy !