...

CXF OAuth2 and OIDC modules are also depending on it.

New: Signature and Verification support for multiparts using JWS Detached Content mode.

New: Optional HTTP Header protection.

Maven Dependencies

Having the following dependency will let developers write JOSE JWS or JWE code:

...

JWS with Detached Content

JWS with a Detached Content provides a way to integrity-protect some data without actually having these data included in the resulting JWS sequence.

For example, if the producer and consumer can both access the same shared piece of data, then the producer can sign these data, post the JWS sequence (without the data) to the consumer. The consumer will validate this JWS sequence and assert the data have not been modified by the time it has received and started validating the sequence. JWS Compact and JWS JSON Producer and Consumer provider constructors accept an optional 'detached' flag in cases were it is required.      

Note the detached content mode is used to support the signing and verification of CXF multipart attachment parts, see below for more information.

JWS with Unencoded Payload

...

Note that JWS Compact uses a '.' as a separator between its 3 parts. JWS with Unencoded Payload recommends that it is the application's responsibility to deal with the unencoded payloads which may have '.' characters. Similarly, JWS JSON unencoded payloads with double quotes will need to be taken care of by the application. 

Note the the signing and verification of CXF multipart attachment parts does depend on this unencoded payload feature, see below for more information.

JWE Encryption

JWE (JSON Web Encryption) document describes how a document content, and, when applicable, a content encryption key, can be encrypted. For example, Appendix A1 shows how the content can be encrypted with a secret key using AesGcm with the actual content encryption key being encrypted using RSA-OAEP.

...

The client code and server configuration is nearly identical to a code/configuration needed to set up JWS Compact filters as shown above, simply replace JwsWriterInterceptor/JwsClientResponseFilter with JwsJsonWriterInterceptor/JwsJsonClientResponseFilter in the client code, and JwsContainerRequestFilter/JwsContainerResponseFilter with JwsJsonContainerRequestFilter/JwsJsonContainerResponseFilter

Signing and Verification of HTTP Attachments

The signing and verification of HTTP request and response attachments is supported starting from CXF 3.1.12.

This feature does not buffer the request and response attachment data and is completely streaming-'friendly'.

It depends on JWS with Detached Content and  JWS with Unencoded Payload options as well as on the newly introduced CXF multipart filters and works as follows.

When request or response attachments are about to be submitted to the Multipart serialization provider, JWS Multipart Output Filter initializes a JWSSignature object. Next every attachment's output stream is replaced with the filtering output stream which updates the signature object on every write operation. Finally this multipart filter adds one more attachment to the list of the attachments to be written - this attachment holds a reference to JWS Signature. When this last attachment is written, JWSSignature produces the signature bytes which are encoded using either JWS Compact or JWS JSON format, with the detached and unencoded content already being pushed to the output stream.

When the attachments are about to be read by the Multipart deserialization provider, their signature carried over in the last attachment part will need to be verified. Just before the attachment parts are about to be read, JWS Multipart Input Filter checks the last attachment part and initializes a JWSVerificationSignature object. Next for every attachment but the last one it replaces the input stream with the filtering input stream which updates the signature verification object on every read operation. Once all the data have been read it compares the calculated signature with the received signature.

Note all of the multipart attachments parts can be secured this way but by default, unless filters set a 'supportSinglePartOnly' property to 'false', the attachments with more than one data part will be rejected. This is done to avoid some possible security side-effects when the receiving side starts processing the parts as soon as they become available, before all of the multipart payload have been read.

Here is the example showing how a Book object (represented as an XML attachment on the wire) can be secured.

First the client and server set up, starting from the client:

@Test
public void testJwsJwkBookHMacMultipart() throws Exception {
    String address = "https://localhost:" + PORT + "/jwsjwkhmacSinglePart";
    BookStore bs = createJwsBookStoreHMac(address, true, false);
    Book book = bs.echoBookMultipart(new Book("book", 123L));
    assertEquals("book", book.getName());
    assertEquals(123L, book.getId());
}
private BookStore createJwsBookStoreHMac(String address, 
                                         boolean supportSinglePart,
                                         boolean useJwsJsonSignatureFormat) throws Exception {
     JAXRSClientFactoryBean bean = createJAXRSClientFactoryBean(address, supportSinglePart, 
                                                                   useJwsJsonSignatureFormat);
     bean.getProperties(true).put("rs.security.signature.properties",
         "org/apache/cxf/systest/jaxrs/security/secret.jwk.properties");

     bean.setServiceClass(BookStore.class);
     bean.setAddress(address);
     List<Object> providers = new LinkedList<Object>();
     JwsMultipartClientRequestFilter outFilter = new JwsMultipartClientRequestFilter();
     outFilter.setSupportSinglePartOnly(supportSinglePart);
     outFilter.setUseJwsJsonSignatureFormat(useJwsJsonSignatureFormat);
     providers.add(outFilter);
     JwsMultipartClientResponseFilter inFilter = new JwsMultipartClientResponseFilter();
     inFilter.setSupportSinglePartOnly(supportSinglePart);
     providers.add(inFilter);
     providers.add(new JwsDetachedSignatureProvider());
     bean.setProviders(providers);
     return bean.create(BookStore.class);
}

and the relevant server code and configuration:

JWE

JweWriterInterceptor creates Compact JWE sequences on the client or server out directions. For example, if you have the client code posting a Book or the server code returning a Book, with this Book representation expected to be encrypted, then add JweWriterInterceptor and set the encryption properties on the JAX-RS client or server.

...