Chapter 161. XML Security component


XML Security component

Available as of Camel 2.12.0
With this Apache Camel component, you can generate and validate XML signatures as described in the W3C standard XML Signature Syntax and Processing or as described in the successor version 1.1. For XML Encryption support, please refer to the XML Security Data Format.
You can find an introduction to XML signature here. The implementation of the component is based on JSR 105, the Java API corresponding to the W3C standard and supports the Apache Santuario and the JDK provider for JSR 105. The implementation will first try to use the Apache Santuario provider; if it does not find the Santuario provider, it will use the JDK provider. Further, the implementation is DOM based.
Since Camel 2.15.0 we also provide support for XAdES-BES/EPES for the signer endpoint; see the section called “XAdES-BES/EPES for the Signer Endpoint”.
Maven users will need to add the following dependency to their pom.xml for this component:
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-xmlsecurity</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>

XML Signature wrapping modes

XML Signature differs between enveloped, enveloping, and detached XML signature. In the enveloped XML signature case, the XML Signature is wrapped by the signed XML Document; which means that the XML signature element is a child element of a parent element, which belongs to the signed XML Document. In the enveloping XML signature case, the XML Signature contains the signed content. All other cases are called detached XML signatures. A certain form of detached XML signature is supported since Camel 2.14.0.
In the enveloped XML signature case, the supported generated XML signature has the following structure (Variables are surrounded by []).
    <[parent element]>
       ... <!-- Signature element is added as last child of the parent element-->
       <Signature Id="generated_unique_signature_id">
           <SignedInfo>
                 <Reference URI=""> 
                       <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                       (<Transform>)* <!-- By default "http://www.w3.org/2006/12/xml-c14n11" is added to the transforms -->
                       <DigestMethod>
                       <DigestValue>
                 </Reference>
                 (<Reference URI="#[keyinfo_Id]">
                       <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                       <DigestMethod>
                       <DigestValue>
                 </Reference>)?
                 <!-- further references possible, see option 'properties' below -->
          </SignedInfo>
          <SignatureValue>
          (<KeyInfo Id="[keyinfo_id]">)?
          <!-- Object elements possible, see option 'properties' below -->
      </Signature>
    </[parent element]>
In the enveloping XML signature case, the supported generated XML signature has the structure:
    <Signature Id="generated_unique_signature_id">
      <SignedInfo>
             <Reference URI="#generated_unique_object_id" type="[optional_type_value]">
                   (<Transform>)* <!-- By default "http://www.w3.org/2006/12/xml-c14n11" is added to the transforms -->
                   <DigestMethod>
                   <DigestValue>
             </Reference>
             (<Reference URI="#[keyinfo_id]">
                   <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                   <DigestMethod>
                   <DigestValue>
             </Reference>)?
              <!-- further references possible, see option 'properties' below  -->
      </SignedInfo>
      <SignatureValue>
      (<KeyInfo Id="[keyinfo_id]">)?
      <Object Id="generated_unique_object_id"/> <!-- The Object element contains the in-message body -->
      <!-- The object ID can either be generated or set by the option parameter "contentObjectId" -->
      <!-- Further Object elements possible, see option 'properties' below -->
    </Signature>
As of Camel 2.14.0 detached XML signatures with the following structure are supported (see also the section called “Detached XML Signatures as Siblings of the Signed Elements”):
(<[signed element] Id="[id_value]">
<!-- signed element must have an attribute of type ID -->
      ...
 
</[signed element]> 
<other sibling/>* 
<!-- between the signed element and the corresponding signature element, there can be other siblings.
 Signature element is added as last sibling. -->
<Signature Id="generated_unique_ID">
           <SignedInfo>
                <CanonicalizationMethod>
                <SignatureMethod>
                <Reference URI="#[id_value]" type="[optional_type_value]">
                <!-- reference URI contains the ID attribute value of the signed element -->
                      (<Transform>)* <!-- By default "http://www.w3.org/2006/12/xml-c14n11" is added to the transforms -->
                      <DigestMethod>
                      <DigestValue>
                </Reference>
                (<Reference URI="#[generated_keyinfo_Id]">
                      <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                      <DigestMethod>
                      <DigestValue>
                </Reference>)?
         </SignedInfo>
         <SignatureValue>
         (<KeyInfo Id="[generated_keyinfo_id]">)?
</Signature>)+

URI format

The camel component consists of two endpoints which have the following URI format.
    xmlsecurity:sign:name[?options]
    xmlsecurity:verify:name[?options]
  • With the signer endpoint, you can generate a XML signature for the body of the in-message which can be either a XML document or a plain text. The enveloped enveloping, or detached (as of Camel 12.14) XML signature(s) will be set to the body of the out-message.
  • With the verifier endpoint, you can validate an enveloped or enveloping XML signature or even several detached (as of Camel 2.14.0) XML signatures contained in the body of the in-message; if the validation is successful, then the original content is extracted from the XML signature and set to the body of the out-message.
  • The name part in the URI can be chosen by the user to distinguish between different signer/verifier endpoints within the camel context.

Basic Example

The following example shows the basic usage of the component.
    from("direct:enveloping").to("xmlsecurity:sign://enveloping?keyAccessor=#accessor",
                                 "xmlsecurity:verify://enveloping?keySelector=#selector","mock:result")
In Spring XML:
    <from uri="direct:enveloping" />
      <to uri="xmlsecurity:sign://enveloping?keyAccessor=#accessor" />
      <to uri="xmlsecurity:verify://enveloping?keySelector=#selector" />
    <to uri="mock:result" />
For the signing process, a private key is necessary. You specify a key accessor bean which provides this private key. For the validation, the corresponding public key is necessary; you specify a key selector bean which provides this public key.
The key accessor bean must implement the KeyAccessor interface. The package org.apache.camel.component.xmlsecurity.api contains the default implementation class DefaultKeyAccessor which reads the private key from a Java keystore.
The key selector bean must implement the javax.xml.crypto.KeySelector interface. The package org.apache.camel.component.xmlsecurity.api contains the default implementation class DefaultKeySelector which reads the public key from a keystore.
In the example, the default signature algorithm http://www.w3.org/2000/09/xmldsig#rsa-sha1 is used. You can set the signature algorithm of your choice by the option signatureAlgorithm (see below). The signer endpoint creates an enveloping XML signature. If you want to create an enveloped XML signature then you must specify the parent element of the Signature element; see option parentLocalName for more details.

Common Signing and Verifying Options

There are options which can be used for both endpoints, signer and verifier.
Name Type Default Description
uriDereferencer javax.xml.crypto.URIDereferencer null URI dereferencer. You can specify here your own URI dereferencer, if you want to restrict the dereferencing or have special requirements for dereferencing.
baseUri String null Base URI used in the URI dereferencer. Relative URIs are concatenated with the base URI.
cryptoContextProperties Map<String, ? extends Object> null Crypto context properties. See javax.xml.crypto.XMLCryptoContext.setProperty(String, Object). The properties can depend on the provider. For example, the JDK provider XMLDSig has the property org.jcp.xml.dsig.validateManifests for enabling manifest validation. The following properties are set by default to the value Boolean.TRUE for the XML verifier: org.jcp.xml.dsig.validateManifests, javax.xml.crypto.dsig.cacheReference. If the secureValidation option is true, additionally the properties org.apache.jcp.xml.dsig.secureValidation and org.jcp.xml.dsig.secureValidation are set to Boolean.TRUE for the XML verifier. If you want to switch these features off you must set the property values to Boolean.FALSE.
disallowDoctypeDecl Boolean Boolean.TRUE Indicator whether DTD DOCTYPE declarations shall be disallowed in the incoming XML message.
omitXmlDeclaration Boolean Boolean.FALSE Indicator whether the XML declaration header shall be omitted in the output XML message.
clearHeaders Boolean Boolean.TRUE Indicator whether the XML signature message headers defined in XmlSignatureConstants shall be deleted at the end of the signer or verifier processing.
schemaResourceUri String null Since Camel 2.14.0. Classpath to the XML Schema file. If set, the XML document is validated against the XML schema. Must be set in the case of detached signatures in order to determine the attributes of type ID. This value can be overwritten by the header CamelXmlSignatureSchemaResourceUri. For further information, see the section called “Detached XML Signatures as Siblings of the Signed Elements”.
outputXmlEncoding String null Since Camel 2.15.0. Character encoding of the output XML document. If null then UTF-8 is used.

Signing Options

The signer endpoint has the following options.
Name Type Default Description
keyAccessor KeyAccessor null Provides the signing key and the KeyInfo instance. There is an example implementation which uses a keystore, see DefaultKeyAccessor
addKeyInfoReference Boolean Boolean.TRUE Indicates whether a Reference element referring to the KeyInfo element provided by the key accessor should be added to the XML signature.
signatureAlgorithm String http://www.w3.org/2000/09/xmldsig#rsa-sha1 signature algorithm consisting of a digest and encryption algorithm. The digest algorithm is used to calculate the digest of the SignedInfo element and the encryption algorithm is used to sign this digest. Possible values: http://www.w3.org/2000/09/xmldsig#dsa-sha1, http://www.w3.org/2000/09/xmldsig#rsa-sha1, http://www.w3.org/2001/04/xmldsig-more#rsa-sha256, http://www.w3.org/2001/04/xmldsig-more#rsa-sha384, http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
digestAlgorithm String see description Digest algorithm for calculating the digest of the in-message body. If not specified then the digest algorithm of the signature algorithm is used. Possible values: http://www.w3.org/2000/09/xmldsig#sha1, http://www.w3.org/2001/04/xmlenc#sha256, http://www.w3.org/2001/04/xmldsig-more#sha384, http://www.w3.org/2001/04/xmlenc#sha512.
parentLocalName String null Local name of the parent of the Signature element. The Signature element will be added at the end of the children of the parent. Necessary for enveloped XML signature. If this option and the parentXpath option are null, an enveloping XML signature is created. See also option parentNamespace. Alternatively you can specify the parent via the option parentXpath.
parentNamespace String null Namespace of the parent of the Signature element. See option parentLocalName
parentXpath XPathFilterParameterSpec null Since Camel 2.15.0. XPath to the parent of the Signature element. The Signature element will be added at the end of the children of the parent. Necessary for enveloped XML signature. If this option and the parentLocalName option are null, an enveloping XML signature is created. Alternatively, you can specify the parent via the option parentLocalName. Example: /p1:root/SecurityItem[last()]. This example will select the last sibling with the name SecurityItem. Such kind of selection is not possible with the option parentLocalName.
canonicalizationMethod javax.xml.crypto.AlgorithmMethod C14n Canonicalization method used to canonicalize the SignedInfo element before the digest is calculated. You can use the helper methods XmlSignatureHelper.getCanonicalizationMethod(String algorithm) or getCanonicalizationMethod(String algorithm, List<String> inclusiveNamespacePrefixes) to create a canonicalization method.
transformMethods List<javax.xml.crypto.AlgorithmMethod> see description Transforms which are executed on the message body before the digest is calculated. By default, C14n is added and in the case of enveloped signature (see option parentLocalName) also http://www.w3.org/2000/09/xmldsig#enveloped-signature is added at position 0 of the list. Use methods in XmlSignatureHelper to create the transform methods.
prefixForXmlSignatureNamespace String ds Prefix for the XML signature namespace. If null is specified or an empty string then no prefix is used for the signature namespace.
contentReferenceUri String See description The URI of the reference to the signed content (in-message body). If null and we are in the enveloped XML signature case then the URI is set to an empty string. If null and we are in the enveloping XML signature case then the URI is set to generated_object_id, which means that the reference points to the Object element containing the in-message body. You can use this option to reference a specific part in your in-message body if you do not want to sign the complete in-message body. This value can be overwritten by the header CamelXmlSignatureContentReferenceUri. Please be aware, if you want to use a value of an XML ID attribute (example: #ID_value), you must provide the information about the ID attribute via a doctype definition contained in the input XML document. This option is ignored in the case of detached signature, when the option xpathsToIdAttributes is set.
contentReferenceType String null Value of the type attribute of the content reference. This value can be overwritten by the header "CamelXmlSignatureContentReferenceType"
plainText Boolean Boolean.FALSE Indicates whether the in-message body contains plain text. Normally, the signature generator treats the incoming message body as XML. If the message body is plain text, then you must set this option to true. The value can be overwritten by the header CamelXmlSignatureMessageIsPlainText.
plainTextEncoding String null Only used when the option plainText is set to true. Then you can specify the encoding of the plain text. If null then UTF-8 is used. The value can be overwritten by the header "CamelXmlSignatureMessageIsPlainTextEncoding".
properties XmlSignatureProperties null For adding additional References and Objects to the XML signature which contain additional properties, you can provide a bean which implements the XmlSignatureProperties interface.
contentObjectId String null Value of the Id attribute of the Object element. Only used in the enveloping XML signature case. If null, a unique value is generated. Available as of 2.12.2
xpathsToIdAttributes
List<XPathFilterParameterSpec>
empty list
Since 2.14.0. List of XPATH expressions to ID attributes of elements to be signed. Used for the detached XML Signatures. Can only be used in combination with the option schemaResourceUri. The value can be overwritten by the header "CamelXmlSignatureXpathsToIdAttributes". If the option parentLocalName is set at the same time then an exception is thrown. The class XPathFilterParameterSpec has the package javax.xml.crypto.dsig.spec. For further information, see sub-chapter "Detached XML Signatures as Siblings of the Signed Elements".
signatureId
String
null
Since 2.14.0. Value of the Id attribute of the Signature element. If null then a unique Id is generated. If the value is the empty string ("") then no Id attribute is added to the Signature element.

Verifying Options

The verifier endpoint has the following options.
Name Type Default Description
keySelector javax.xml.crypto.KeySelector null Provides the key for validating the XML signature. There is an example implementation which uses a keystore, see DefaultKeySelector.
xmlSignatureChecker XmlSignatureChecker null This interface allows the application to check the XML signature before the validation is executed. This step is recommended in http://www.w3.org/TR/xmldsig-bestpractices/#check-what-is-signed
validationFailedHandler ValidationFailedHandler DefaultValidationFailedHandler Handles the different validation failed situations. The default implementation throws specific exceptions for the different situations (All exceptions have the package name org.apache.camel.component.xmlsecurity.api and are a sub-class of XmlSignatureInvalidException. If the signature value validation fails, a XmlSignatureInvalidValueException is thrown. If a reference validation fails, a XmlSignatureInvalidContentHashException is thrown. For more detailed information, see the JavaDoc.
xmlSignature2Message XmlSignature2Message DefaultXmlSignature2Message Bean which maps the XML signature to the ouput-message after the validation. How this mapping should be done can be configured by the options outputNodeSearchType, outputNodeSearch, and removeSignatureElements. The default implementation offers three possibilities which are related to the three output node search types "Default", "ElementName", and "XPath". The default implementation determines a node which is then serialized and set to the body of the ouput message. If the search type is "ElementName" then the ouput node (which must be in this case an element) is determined by the local name and namespace defined in the search value (see option outputNodeSearch). If the search type is "XPath" then the output node is determined by the XPath specified in the search value (in this case the ouput node can be of type "Element", "TextNode" or "Document"). If the output node search type is "Default" then the following rules apply: In the enveloped XML signature case (there is a reference with URI="" and transform "http://www.w3.org/2000/09/xmldsig#enveloped-signature"), the incoming XML document without the Signature element is set to the output message body. In the non-enveloped XML signature case, the message body is determined from a referenced Object; this is explained in more detail in chapter "Output Node Determination in Enveloping XML Signature Case".
outputNodeSearchType String "Default" Determines the type of the search of the output node. See option xmlSignature2Message. The default implementation DefaultXmlSignature2Message supports the three search types "Default", "ElementName", and "XPath".
outputNodeSearch Object null Search value of the output node search. The type depends on the search type. For the default search implementation DefaultXmlSignature2Message the following values can be supplied. If the search type is "Default", then the search value is not used. If the search type is "ElementName", then the search value contains the namespace and local name of the output element. The namespace must be embraced in brackets. If the search type is "XPath", the search value contains an instance of javax.xml.crypto.dsig.spec.XPathFilterParameterSpec which represents an XPath. You can create such an instance via the method XmlSignatureHelper.getXpathFilter(String xpath, Map<String, String> namespaceMap). The XPath determines the output node which can be of type Element, TextNode, or Document.
removeSignatureElements Boolean Boolean.FALSE Indicator for removing Signature elements in the output message in the enveloped XML signature case. Used in the XmlSignature2Message instance. The default implementation does use this indicator for the two search types "ElementName" and "XPath".
secureValidation Boolean Boolean.TRUE Enables secure validation. If true then secure validation is enabled - see here for more information.

Output Node Determination in Enveloping XML Signature Case

After the validation the node is extracted from the XML signature document which is finally returned to the output-message body. In the enveloping XML signature case, the default implementation DefaultXmlSignature2Message of XmlSignature2Message does this for the node search type "Default" in the following way (see option xmlSignature2Message):
First an Object reference is determined:
  • Only same document references are taken into account (URI must start with '#')
  • Also indirect same document references to an object via manifest are taken into account.
  • The resulting number of Object references must be 1.
Then, the Object is dereferenced and the Object must only contain one XML element. This element is returned as output node.
This does mean that the enveloping XML signature must have either the structure
    <Signature>
          <SignedInfo>
             <Reference URI="#object"/>       
             <!-- further references possible but they must not point to an Object or Manifest containing an object reference -->
             ...
          </SignedInfo>
      
          <Object Id="object">
               <!-- contains one XML element which is extracted to the message body -->
          <Object>
          <!-- further object elements possible which are not referenced-->
          ...
          (<KeyInfo>)?
    </Signature>
or the structure
    <Signature>
          <SignedInfo>
             <Reference URI="#manifest"/>       
             <!-- further references  are possible but they must not point to an Object or other manifest containing an object reference -->
             ...
          </SignedInfo>
      
          <Object >
             <Manifest Id="manifest">
                <Reference URI=#object/>
             </Manifest>
          </Objet>
          <Object Id="object">
              <!-- contains the DOM node which is extracted to the message body -->
          </Object>
           <!-- further object elements possible which are not referenced -->
          ...
          (<KeyInfo>)?
    </Signature>

Detached XML Signatures as Siblings of the Signed Elements

Since 2.14.0.
You can create detached signatures where the signature is a sibling of the signed element. The following example contains two detached signatures. The first signature is for the element "C" and the second signature is for element "A". The signatures are nested; the second signature is for the element A which also contains the first signature.

Example 161.1. Example Detached XML Signatures

<?xml version="1.0" encoding="UTF-8" ?>
<root>
    <A ID="IDforA">
        <B>
            <C ID="IDforC">
                <D>dvalue</D>
            </C>
            <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
                Id="_6bf13099-0568-4d76-8649-faf5dcb313c0">
                <ds:SignedInfo>
                    <ds:CanonicalizationMethod
                        Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
                    <ds:SignatureMethod
                        Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
                    <ds:Reference URI="#IDforC">
                        ...
                    </ds:Reference>
                </ds:SignedInfo>
                <ds:SignatureValue>aUDFmiG71</ds:SignatureValue>
            </ds:Signature>
        </B>
    </A>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"Id="_6b02fb8a-30df-42c6-ba25-76eba02c8214">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod
                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
            <ds:SignatureMethod
                Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
            <ds:Reference URI="#IDforA">
                ...
            </ds:Reference>         
        </ds:SignedInfo>
        <ds:SignatureValue>q3tvRoGgc8cMUqUSzP6C21zb7tt04riPnDuk=</ds:SignatureValue>
    </ds:Signature>
<root>
The example shows that you can sign several elements and that for each element a signature is created as sibling. The elements to be signed must have an attribute of type ID. The ID type of the attribute must be defined in the XML schema (see option schemaResourceUri). You specify a list of XPATH expressions pointing to attributes of type ID (see option xpathsToIdAttributes). These attributes determine the elements to be signed. The elements are signed by the same key given by the keyAccessor bean. Ements with higher (=deeper) hierarachy level are signed first. In the example, the element "C" is signed before the element "A".

Example 161.2. Java DSL Example

from("direct:detached")
  .to("xmlsecurity:sign://detached?keyAccessor=#keyAccessorBeant&xpathsToIdAttributes=#xpathsToIdAttributesBean&schemaResourceUri=Test.xsd")
  .to("xmlsecurity:verify://detached?keySelector=#keySelectorBean&schemaResourceUri=org/apache/camel/component/xmlsecurity/Test.xsd")
  .to("mock:result");

Example 161.3. Spring Example

   
  <bean id="xpathsToIdAttributesBean" class="java.util.ArrayList">
        <constructor-arg type="java.util.Collection">
            <list>
                <bean
                    class="org.apache.camel.component.xmlsecurity.api.XmlSignatureHelper"
                    factory-method="getXpathFilter">
                    <constructor-arg type="java.lang.String"
                        value="/ns:root/a/@ID" />
                    <constructor-arg>
                        <map key-type="java.lang.String" value-type="java.lang.String">
                            <entry key="ns" value="http://test" />
                        </map>
                    </constructor-arg>
                </bean>
            </list>
        </constructor-arg>
    </bean>
...
       <from uri="direct:detached" />
            <to
                uri="xmlsecurity:sign://detached?keyAccessor=#keyAccessorBean&amp;xpathsToIdAttributes=#xpathsToIdAttributesBean&amp;schemaResourceUri=Test.xsd" />
            <to
                uri="xmlsecurity:verify://detached?keySelector=#keySelectorBean&amp;schemaResourceUri=Test.xsd" />
            <to uri="mock:result" />

XAdES-BES/EPES for the Signer Endpoint

Available as of Camel 2.15.0 ŸXML Advanced Electronic Signatures (XAdES) defines extensions to XML Signature. This standard was defined by the European Telecomunication Standards Institute and allows you to create signatures which are compliant to the European Union Directive (1999/93/EC) on a Community framework for electronic signatures. XAdES defines different sets of signature properties which are called signature forms. We support the signature forms Basic Electronic Signature (XAdES-BES) and Explicit Policy Based Electronic Signature (XAdES-EPES) for the Signer Endpoint. The forms Electronic Signature with Validation Data XAdES-T and XAdES-C are not supported. We support the following properties of the XAdES-EPES form ("?" denotes zero or one occurrence):
        <QualifyingProperties Target>
            <SignedProperties>
                <SignedSignatureProperties>
                    (SigningTime)?
                    (SigningCertificate)?
                    (SignaturePolicyIdentifier)
                    (SignatureProductionPlace)?
                    (SignerRole)?
                </SignedSignatureProperties>
                <SignedDataObjectProperties>
                    (DataObjectFormat)?
                    (CommitmentTypeIndication)?
                </SignedDataObjectProperties>
            </SignedProperties>
        </QualifyingProperties>
The properties of the XAdES-BES form are the same except that the SignaturePolicyIdentifier property is not part of XAdES-BES.
You can configure the XAdES-BES/EPES properties via the bean org.apache.camel.component.xmlsecurity.api.XAdESSignatureProperties or org.apache.camel.component.xmlsecurity.api.DefaultXAdESSignatureProperties. XAdESSignatureProperties does support all properties mentioned above except the SigningCertificate property. To get the SigningCertificate property, you must overwrite either the method XAdESSignatureProperties.getSigningCertificate() or XAdESSignatureProperties.getSigningCertificateChain(). The class DefaultXAdESSignatureProperties overwrites the method getSigningCertificate() and allows you to specify the signing certificate via a keystore and alias. The following example shows all parameters you can specify. If you do not need certain parameters you can just omit them.
        Keystore keystore = ... // load a keystore
        DefaultKeyAccessor accessor = new DefaultKeyAccessor();
        accessor.setKeyStore(keystore);
        accessor.setPassword("password");
        accessor.setAlias("cert_alias"); // signer key alias
 
        DefaultXAdESSignatureProperties props = new DefaultXAdESSignatureProperties();
        props.setNamespace("http://uri.etsi.org/01903/v1.3.2#"); // sets the namespace for the XAdES elements; the namspace is related to the XAdES version, default value is "http://uri.etsi.org/01903/v1.3.2#", other possible values are "http://uri.etsi.org/01903/v1.1.1#" and "http://uri.etsi.org/01903/v1.2.2#"
        props.setPrefix("etsi"); // sets the prefix for the XAdES elements, default value is "etsi"
        
        // signing certificate
        props.setKeystore(keystore));
        props.setAlias("cert_alias"); // specify the alias of the signing certificate in the keystore = signer key alias
        props.setDigestAlgorithmForSigningCertificate(DigestMethod.SHA256); // possible values for the algorithm are "http://www.w3.org/2000/09/xmldsig#sha1", "http://www.w3.org/2001/04/xmlenc#sha256", "http://www.w3.org/2001/04/xmldsig-more#sha384", "http://www.w3.org/2001/04/xmlenc#sha512", default value is "http://www.w3.org/2001/04/xmlenc#sha256"
        props.setSigningCertificateURIs(Collections.singletonList("http://certuri"));
 
        // signing time
        props.setAddSigningTime(true);
 
        // policy
        props.setSignaturePolicy(XAdESSignatureProperties.SIG_POLICY_EXPLICIT_ID);
        // also the values XAdESSignatureProperties.SIG_POLICY_NONE ("None"), and XAdESSignatureProperties.SIG_POLICY_IMPLIED ("Implied")are possible, default value is XAdESSignatureProperties.SIG_POLICY_EXPLICIT_ID ("ExplicitId")
        // For "None" and "Implied" you must not specify any further policy parameters
        props.setSigPolicyId("urn:oid:1.2.840.113549.1.9.16.6.1");
        props.setSigPolicyIdQualifier("OIDAsURN"); //allowed values are empty string, "OIDAsURI", "OIDAsURN"; default value is empty string
        props.setSigPolicyIdDescription("invoice version 3.1");
        props.setSignaturePolicyDigestAlgorithm(DigestMethod.SHA256);// possible values for the algorithm are "http://www.w3.org/2000/09/xmldsig#sha1", http://www.w3.org/2001/04/xmlenc#sha256", "http://www.w3.org/2001/04/xmldsig-more#sha384", "http://www.w3.org/2001/04/xmlenc#sha512", default value is http://www.w3.org/2001/04/xmlenc#sha256"
        props.setSignaturePolicyDigestValue("Ohixl6upD6av8N7pEvDABhEL6hM=");
        // you can add  qualifiers for the signature policy either by specifying text or an XML fragment with the root element "SigPolicyQualifier" 
        props.setSigPolicyQualifiers(Arrays
            .asList(new String[] {
                "<SigPolicyQualifier xmlns=\"http://uri.etsi.org/01903/v1.3.2#\"><SPURI>http://test.com/sig.policy.pdf</SPURI><SPUserNotice><ExplicitText>display text</ExplicitText>"
                    + "</SPUserNotice></SigPolicyQualifier>", "category B" }));
        props.setSigPolicyIdDocumentationReferences(Arrays.asList(new String[] {"http://test.com/policy.doc.ref1.txt",
            "http://test.com/policy.doc.ref2.txt" }));
 
        // production place
        props.setSignatureProductionPlaceCity("Munich");
        props.setSignatureProductionPlaceCountryName("Germany");
        props.setSignatureProductionPlacePostalCode("80331");
        props.setSignatureProductionPlaceStateOrProvince("Bavaria");
 
        //role
        // you can add claimed roles either by specifying text or an XML fragment with the root element "ClaimedRole" 
        props.setSignerClaimedRoles(Arrays.asList(new String[] {"test",
            "<a:ClaimedRole xmlns:a=\"http://uri.etsi.org/01903/v1.3.2#\"><TestRole>TestRole</TestRole></a:ClaimedRole>" }));
        props.setSignerCertifiedRoles(Collections.singletonList(new XAdESEncapsulatedPKIData("Ahixl6upD6av8N7pEvDABhEL6hM=",
            "http://uri.etsi.org/01903/v1.2.2#DER", "IdCertifiedRole")));
 
        // data object format
        props.setDataObjectFormatDescription("invoice");
        props.setDataObjectFormatMimeType("text/xml");
        props.setDataObjectFormatIdentifier("urn:oid:1.2.840.113549.1.9.16.6.2");
        props.setDataObjectFormatIdentifierQualifier("OIDAsURN"); //allowed values are empty string, "OIDAsURI", "OIDAsURN"; default value is empty string
        props.setDataObjectFormatIdentifierDescription("identifier desc");
        props.setDataObjectFormatIdentifierDocumentationReferences(Arrays.asList(new String[] {
            "http://test.com/dataobject.format.doc.ref1.txt", "http://test.com/dataobject.format.doc.ref2.txt" }));
 
        //commitment
        props.setCommitmentTypeId("urn:oid:1.2.840.113549.1.9.16.6.4");
        props.setCommitmentTypeIdQualifier("OIDAsURN"); //allowed values are empty string, "OIDAsURI", "OIDAsURN"; default value is empty string
        props.setCommitmentTypeIdDescription("description for commitment type ID");
        props.setCommitmentTypeIdDocumentationReferences(Arrays.asList(new String[] {"http://test.com/commitment.ref1.txt",
            "http://test.com/commitment.ref2.txt" }));
        // you can specify a commitment type qualifier either by simple text or an XML fragment with root element "CommitmentTypeQualifier"
        props.setCommitmentTypeQualifiers(Arrays.asList(new String[] {"commitment qualifier",
            "<c:CommitmentTypeQualifier xmlns:c=\"http://uri.etsi.org/01903/v1.3.2#\"><C>c</C></c:CommitmentTypeQualifier>" }));
 
 beanRegistry.bind("xmlSignatureProperties",props);
 beanRegistry.bind("keyAccessorDefault",keyAccessor);
 
 // you must reference the properties bean in the "xmlsecurity" URI
 from("direct:xades").to("xmlsecurity:sign://xades?keyAccessor=#keyAccessorDefault&properties=#xmlSignatureProperties")
                     .to("mock:result");

   ...
   <from uri="direct:xades" />
            <to
                uri="xmlsecurity:sign://xades?keyAccessor=#accessorRsa&amp;properties=#xadesProperties" />
            <to uri="mock:result" />
   ...
   <bean id="xadesProperties"
        class="org.apache.camel.component.xmlsecurity.api.XAdESSignatureProperties">
        <!-- For more properties see the the previous Java DSL example. 
             If you want to have a signing certificate then use the bean class DefaultXAdESSignatureProperties (see the previous Java DSL example). -->
        <property name="signaturePolicy" value="ExplicitId" />
        <property name="sigPolicyId" value="http://www.test.com/policy.pdf" />
        <property name="sigPolicyIdDescription" value="factura" />
        <property name="signaturePolicyDigestAlgorithm" value="http://www.w3.org/2000/09/xmldsig#sha1" />
        <property name="signaturePolicyDigestValue" value="Ohixl6upD6av8N7pEvDABhEL1hM=" />
        <property name="signerClaimedRoles" ref="signerClaimedRoles_XMLSigner" />
        <property name="dataObjectFormatDescription" value="Factura electrónica" />
        <property name="dataObjectFormatMimeType" value="text/xml" />
    </bean>
    <bean class="java.util.ArrayList" id="signerClaimedRoles_XMLSigner">
        <constructor-arg>
            <list>
                <value>Emisor</value>
                <value>&lt;ClaimedRole
                    xmlns=&quot;http://uri.etsi.org/01903/v1.3.2#&quot;&gt;&lt;test
                    xmlns=&quot;http://test.com/&quot;&gt;test&lt;/test&gt;&lt;/ClaimedRole&gt;</value>
            </list>
        </constructor-arg>
    </bean>

Headers

Header Type Description
CamelXmlSignatureXAdESQualifyingPropertiesId
String for the 'Id' attribute value of QualifyingProperties element
CamelXmlSignatureXAdESSignedDataObjectPropertiesId
String for the 'Id' attribute value of SignedDataObjectProperties element
CamelXmlSignatureXAdESSignedSignaturePropertiesId
String for the 'Id' attribute value of SignedSignatureProperties element
CamelXmlSignatureXAdESDataObjectFormatEncoding
String for the value of the Encoding element of the DataObjectFormat element
CamelXmlSignatureXAdESNamespace String overwrites the XAdES namespace parameter value
CamelXmlSignatureXAdESPrefix
String overwrites the XAdES prefix parameter value

Limitations with regard to XAdES version 1.4.2

  • No support for signature form XAdES-T and XAdES-C
  • Only signer part implemented. Verifier part currently not available.
  • No support for the 'QualifyingPropertiesReference' element (see section 6.3.2 of spec).
  • No support for the Transforms element contained in the SignaturePolicyId element contained in the SignaturePolicyIdentifier element
  • No support of the CounterSignature element --> no support for the UnsignedProperties element
  • At most one DataObjectFormat element. More than one DataObjectFormat element makes no sense because we have only one data object which is signed (this is the incoming message body to the XML signer endpoint).
  • At most one CommitmentTypeIndication element. More than one CommitmentTypeIndicationelement makes no sense because we have only one data object which is signed (this is the incoming message body to the XML signer endpoint).
  • A CommitmentTypeIndication element contains always the AllSignedDataObjects element. The ObjectReference element within CommitmentTypeIndication element is not supported.
  • The AllDataObjectsTimeStamp element is not supported
  • The IndividualDataObjectsTimeStamp element is not supported

See Also

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.