CXF adds support for the HTTP Signatures draft spec since CXF 3.3.0. This provides an alternative to providing message integrity other than XML Security and JOSE, and in fact provides a stronger measure of message integrity as it allows the incorporation of HTTP headers in the signature, including the HTTP method and path.
The following dependency is required to use CXF's HTTP Signature implementation.
CXF supports HTTP Signature creation and verification on both the client and service side. Payload integrity is supported by digesting the payload and inserting the result into a "Digest" header, which is also signed by HTTP Signature.
To enable HTTP Signature in CXF, it is necessary to add one of the following providers to the client or endpoint:
- Client / Service Outbound Signature Creation: org.apache.cxf.rs.security.httpsignature.filters.CreateSignatureInterceptor
- Client Inbound Signature Verification: org.apache.cxf.rs.security.httpsignature.filters.VerifySignatureClientFilter
- Service Inbound Signature Verification: org.apache.cxf.rs.security.httpsignature.filters.VerifySignatureFilter
For example in code:
and in Spring:
Fine grained Configuration
As well as adding the desired providers (see above), we need to configure them (for example the keys to use, the headers to sign, etc.). There are two options for doing this. In this section we'll look at configuring the providers directly, which allows for a more fine-grained configuration. See below for an alternative using configuration properties that retrieves keys from keystores.
For outbound signature we need to configure the CreateSignatureInterceptor provider with a MessageSigner instance. The MessageSigner contains a number of different constructors that can be used depending on the desired functionality. At a minimum, we need to supply the PrivateKey instance to sign the message, as well as the "Key Id" as defined in the spec. We can also supply the signature algorithm name - if not specified this defaults to "rsa-sha256". Similarly we can supply the security provider name, which defaults to "SunRsaSign".
We can also supply a list of HTTP headers to sign. By default it signs all of the HTTP headers that are made available to it by CXF. On the client side it will also sign the HTTP method and Path via "(request-target)".
Here is an example from the tests:
For signature verification, we need to supply the VerifySignatureClientFilter and VerifySignatureFilter instances with a MessageVerifier instance. At a minimum, we need to configure the MessageVerifier with a KeyProvider instance, which is an interface which supplies the key required to verify the signature given the "Key Id" present in the message. As per MessageSigner, we can also specify the signature algorithm that is required, as well as the Security Provider. It defaults to the same values as documented for MessageSigner above. We can also specify a list of HTTP headers which must be signed. In addition to this list, the default behavior is to require that the "digest" header is signed (unless a service request with a HTTP method of GET or HEAD, and also unless a service response and the status is 204 or not "OK"), as well as the "(request-target)" header for a client request. This default behaviour can be disabled by setting the boolean addDefaultRequiredHeaders property of MessageVerifier to false.
Here is an example from the tests:
An alternative to configure the MessageSigner, MessageVerifier instances as documented in the previous section is to use the following security configuration properties instead. These properties rely on obtaining the private keys to sign the messages, as well as the public keys used to verify the messages, from a keystore stored in the local filesystem. Note that the "Key Id" is ignored, we verify the message using the public key defined in the configuration properties.
The following configuration properties can be used to configure HTTP Signature with the various filters. Note that they are shared for the most part with JAX-RS JOSE.
|rs.security.keystore||The Java KeyStore Object to use. This configuration tag is used if you want to pass the KeyStore Object through dynamically.|
The keystore type.
|rs.security.keystore.password||The password required to access the keystore.|
|rs.security.keystore.alias||The keystore alias corresponding to the key to use.|
|rs.security.keystore.file||The path to the keystore file.|
|rs.security.key.password||The password required to access the private key (in the keystore).|
|rs.security.key.password.provider||A reference to a PrivateKeyPasswordProvider instance used to retrieve passwords to access keys.|
The signature properties file for Compact or JSON signature creation. If not specified then it falls back to "rs.security.signature.properties".
The signature properties file for Compact or JSON signature verification. If not specified then it falls back to "rs.security.signature.properties".
|rs.security.signature.properties||The signature properties file for Compact or JSON signature creation/verification.|
|rs.security.signature.algorithm||rsa-sha256||The signature algorithm to use.|
|rs.security.http.signature.key.id||The signature key id. This is a required configuration option on the outbound side.|
|rs.security.http.signature.out.headers||all headers incl "(request-target)"|
A list of String values which correspond to the list of HTTP headers that will be signed in the outbound request.
|rs.security.http.signature.in.headers||"digest", and "(request-target)" for a client request.|
A list of String values which correspond to the list of HTTP headers that must be signed in the inbound request. By default, a client request must sign "(request-target)". In addition, a client request must sign "digest", unless it is a GET/HEAD request. A service response must sign "digest" for all "OK" status codes, apart from 204.
|rs.security.http.signature.digest.algorithm||SHA-256||The digest algorithm to use when digesting the payload.|
Here is a Java example:
where "alice.httpsig.properties" looks like:
Here is a spring example: