The Java code for this recipe is located in the org.camelcookbook.security.signatures package. The Spring XML files are located under src/main/resources/META-INF/spring and prefixed with signatures.

To use Camel's Crypto Component, you need to add a dependency on the camel-crypto library.

Add the following to the dependencies section of your Maven POM:

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-crypto</artifactId>
  <version>${camel-version}</version>
</dependency>
<dependency>
  <groupId>commons-codec</groupId>
  <artifactId>commons-codec</artifactId>
  <version>1.8</version> <!-- Java 6+ -->
</dependency>

To make life easier around accessing keystores in the Spring XML DSL, we will use the spring-crypto-utils library. This is not strictly required, but otherwise you would need to write some Java factory methods that Spring can call for the purpose of instantiating KeyStore objects.

<dependency>
  <groupId>com.google.code.spring-crypto-utils</groupId>
  <artifactId>spring-crypto-utils</artifactId>
  <version>1.3.0</version>
</dependency>

Before using the cryptographic capabilities available in Camel you will need:

For the purposes of this example, we will use the keytool utility that is included as part of the Java Development Kit (JDK):

The steps mentioned in the preceding list will generate keys using the DSA algorithm, and hash it using SHA1. The full signature algorithm will therefore be SHA1withDSA; the same as the default algorithm used by camel-crypto.

In order to perform message signing and verification, you will need to do the following:

In the sign phase, the Camel Crypto Component calculates a signature using the password and key specified, and Base64 encodes it before inserting it into the exchange's CamelDigitalSignature header.

These digital signature header names are defined as constants in the org.apache.camel.component.crypto.DigitalSignatureConstants class. For example, the CamelDigitalSignature header is defined in DigitalSignatureConstants.SIGNATURE.

It is up to your routing code to take that header value and pass it appropriately via the transport being used to the system you are communicating with. Likewise, if consuming from a transport, you need to take the signature from the transport mechanism and place it into the CamelDigitalSignature header for verification.

The verify phase looks up the truststore for the public key of the system it expects the message to have come from (in our case system_a), and checks the signature against the public key. If the message was modified after being signed, or the key to check the signature against is missing or is not the correct public key, the verify step will throw a java.security.SignatureException.

This ability to verify gives a certainty that the payload is exactly what was sent. It also provides a mechanism for non-repudiation since only a message signed with the private key of the sender can be verified using their public key.

You can change the message signature header that is to be written to when signing, or that is used for verification by setting the signatureHeader URI attribute to another value:

crypto:sign://usingKeystore?keystore=#keyStore&alias=system_a&password=keyPasswordA&signatureHeader=mySignature

If you are receiving messages from a number of systems, each of which has its own key pair and signs its messages differently, it is possible to dynamically determine the alias to use from the truststore. To do this, set the CamelSignatureKeyStoreAlias (DigitalSignatureConstants.KEYSTORE_ALIAS) header before invoking the crypto: endpoint.

For example, in the following Java DSL fragment the calling routes indicate to the verification route which system signed the message so that the appropriate key can be fetched from the store. The third route ("direct:verify") sets the CamelSignatureKeyStoreAlias header, which is then used to verify the signature using the named key from its truststore:

from("direct:sign_a")
  .to("crypto:sign://usingKeystore?keystore=#keyStore&alias=system_a&password=keyPasswordA")
  .setHeader("sendingSystem", constant("a"))
  .to("direct:verify");

from("direct:sign_b")
   .to("crypto:sign://usingKeystore?keystore=#keyStore&alias=system_b&password=keyPasswordB")
   .setHeader("sendingSystem", constant("b"))
   .to("direct:verify");

from("direct:verify")
  .setHeader(DigitalSignatureConstants.KEYSTORE_ALIAS, 
      simple("system_${header[sendingSystem]}"))
  .to("crypto:verify//usingKeystore?keystore=#trustStore")
  .to("mock:verified");

A CamelSignatureKeyStorePassword (DigitalSignatureConstants.KEYSTORE_PASSWORD) header is also available for use if you would like to dynamically provide the password for the keystore during the signing phase.

The Camel Crypto Component also supports the use of public and private keys directly without using keystores. For an overview of how to do this, you should refer to the Camel Crypto for Digital Signatures documentation.