LDAP support in Apache Camel

Apache Camel allows you to add LDAP queries to your Camel routes via the camel-ldap and camel-spring-ldap components. The camel-ldap component allows you to perform an LDAP query using a filter as the message payload. The spring-ldap component is a wrapper for Spring LDAP, and is a bit more advanced than the camel-ldap component, in that it also supports the "bind" and "unbind" operations, in addition to "search".

I've created two test-cases that show how to use each of these components. Both test-cases use the Camel file component to read in files that contain LDAP queries. These queries are then dispatched to an Apache DS server that is configured via annotations in the test code, using an LDIF file containing some test data. The results are then processed and written out in the target directory. The test-cases are available here. 

Apache Santuario - XML Security for Java 2.0.3 and 1.5.8 released

Versions 2.0.3 and 1.5.8 of Apache Santuario - XML Security for Java have been released. Version 2.0.3 contains a critical security advisory (CVE-2014-8152) in relation to the new streaming XML Signature support introduced in version 2.0.0:

For certain XML documents, it is possible to modify the document and the streaming XML Signature verification code will not report an error when trying to validate the signature.

Please note that the "in-memory" (DOM) API for XML Signature is not affected by this issue, nor is the JSR-105 API. Also, web service stacks that use the streaming functionality of Apache Santuario (such as Apache CXF/WSS4J) are also not affected by this vulnerability.

Apart from this issue, version 2.0.3 contains a significant performance improvement, and both releases contain minor bug fixes and dependency upgrades.

XML Advanced Electronic Signature (XAdES) support in Apache Camel

I have previously covered some XML Signature and Encryption testcases in Apache Camel. Camel 2.15 will feature some new limited support for XML Advanced Electronic Signatures (XAdES) in the XML Security component. This post will briefly cover what XML Advanced Electronic Signatures are, and show how they can be produced in Camel. No support exists yet for validating XAdES Signatures in Camel. Note that as Camel 2.15 is not yet released, some of the details are subject to change.

XML Signature has a number of shortcomings in terms of conveying meta-data describing the signing process to the recipient. It does not include the signing certificate/key in the signature itself. It does not tell the recipient when or where the signature was created, which role the signer had at the time of signing, what format the signed data is in, what the signature policy was, etc. XAdES attempts to solve these problems by introducing standard properties that are inserted into the "Object" part of an XML Signature. Some of these properties are then included in the message signature.

Camel 2.15 will support XAdES in the XML Security component by a new "properties" configuration option, which must reference a XAdESSignatureProperties implementation. I added a new test to the camel-xmlsecurity project in github that illustrates how to do this. The spring configuration for the test is here. The xmlsecurity route links to a DefaultXAdESSignatureProperties implementation, which is configured with the signing key (and alias), an "Implied" Signature policy, and a role of "employee". The resulting ds:Object in the XML Signature looks like:

<ds:Object>
  <etsi:QualifyingProperties xmlns:etsi="..." Target="#...">
    <etsi:SignedProperties Id="_1c03790b-8e46-4837-85bc-d6562e4c713c"> 
      <etsi:SignedSignatureProperties>
        <etsi:SigningTime>2015-01-14T11:19:49Z</etsi:SigningTime>
        <etsi:SigningCertificate>
          <etsi:Cert>
            <etsi:CertDigest>
              <ds:DigestMethod Algorithm="...#sha256"/>
              <ds:DigestValue>KsquBA...=</ds:DigestValue>
            </etsi:CertDigest>
            <etsi:IssuerSerial>
              <ds:X509IssuerName>...,C=US</ds:X509IssuerName>
              <ds:X509SerialNumber>1063337...</ds:X509SerialNumber>
            </etsi:IssuerSerial>
          </etsi:Cert>
        </etsi:SigningCertificate>
        <etsi:SignaturePolicyIdentifier>
          <etsi:SignaturePolicyImplied/>
        </etsi:SignaturePolicyIdentifier>
        <etsi:SignerRole>
          <etsi:ClaimedRoles>
            <etsi:ClaimedRole>employee</etsi:ClaimedRole>
          </etsi:ClaimedRoles>
        </etsi:SignerRole>
      </etsi:SignedSignatureProperties>
    </etsi:SignedProperties>
  </etsi:QualifyingProperties>
</ds:Object>

Signing and encrypting Apache Camel routes

A recent blog post looked at using the XML Security component and dataformat in Apache Camel to sign and encrypt XML documents. However, what if you wish to secure non-XML data? An alternative is to use the Apache Camel Crypto component and dataformat. The Crypto component provides the ability to sign (and verify) messages (using the JCE). Similarly, the Crypto dataformat allows you to encrypt (and decrypt) messages (again using the JCE). Another alternative is to use the PGPDataFormat, which allows you to use PGP to sign/encrypt Camel messages.

I have created a github project called "camel-crypto" with some samples about how to use these features. It contains the following tests:

• CryptoEncryptionTest: Use the Crypto dataformat to encrypt/decrypt messages
• CryptoSignatureTest: Use the Crypto component to sign/verify messages
• PGPEncryptionTest: Use the PGPDataFormat to encrypt/decrypt messages
• PGPSignatureEncryptionTest: Use the PGPDataFormat to sign + encrypt messages

The tests follow a similar pattern, where they take some (XML) data, sign/encrypt it, and copy it to a particular directory. Another route then takes the secured data, and verifies/decrypts it, and copies it to another directory. The tests also show how to use the Camel Jasypt component to avoid hard-coding plaintext passwords in the spring configuration files. The tests rely on a SNAPSHOT version of Camel (2.15-SNAPSHOT) at the time of writing this post, due to some fixes that were required (particularly in terms of adding new (Spring) configuration options to the PGPDataFormat).