...
Maven users will need to add the following dependency to their pom.xml
for this component:
Code Block | ||||
---|---|---|---|---|
| ||||
<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 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. Detached XML signatures are not supported in the current implementationA certain form of detached XML signature is supported since 2.14.0.
In the enveloped XML signature case, the supported generated XML signature has the following structure (Variables are surrounded by []).
Code Block |
---|
<[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:
Code Block |
---|
<Signature Id="generated_unique_signature_id"> <SignedInfo> <Reference URI="#generated_unique_object_id" type="[optional_type_value]"> <!-- the URI can also be set by the option 'contentReferenceUri'; see below. --> (<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> |
URI format
The camel component consists of two endpoints which have the following URI format.
Code Block |
---|
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 or enveloping XML signature will be set to the body of the out-message.
- With the verifier endpoint, you can validate an enveloped or enveloping XML signature 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 one camel context.
Basic Example
The following example shows the basic usage of the component.
As of 2.14.0 detached XML signatures with the following structure are supported (see also sub-chapter XML Signatures as Siblings of Signed Elements):
Code Block | ||
---|---|---|
| ||
(<[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">
| ||
Code Block | ||
from("direct:enveloping").to("xmlsecurity:sign://enveloping?keyAccessor=#accessor", <SignedInfo> <CanonicalizationMethod> "xmlsecurity:verify://enveloping?keySelector=#selector","mock:result") |
In Spring XML:
Code Block |
---|
<from uri="direct:enveloping" /> <SignatureMethod> <to uri="xmlsecurity:sign://enveloping?keyAccessor=#accessor" /> <to<Reference uri="xmlsecurity:verify://enveloping?keySelector=#selector" /URI="#[id_value]" type="[optional_type_value]"> <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.
Wiki Markup |
---|
{div:class=confluenceTableSmall}{div} |
Name | Type | Default | Description |
---|---|---|---|
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 |
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. |
Signing Options
The signer endpoint has the following options.
Wiki Markup |
---|
{div:class=confluenceTableSmall}{div} |
...
Name
...
Type
...
Default
...
Description
...
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
...
Indicator whether a Reference element refering the KeyInfo element provided by the key accessor should be added to the XML signature.
<!-- 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.
Code Block |
---|
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 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 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.
Code Block |
---|
from("direct:enveloping").to("xmlsecurity:sign://enveloping?keyAccessor=#accessor",
"xmlsecurity:verify://enveloping?keySelector=#selector","mock:result")
|
In Spring XML:
Code Block |
---|
<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.
...
signatureAlgorithm
...
String
In the example, the default signature algorithm
http://www.w3.org/2000/09/xmldsig#rsa-sha1
...
is used. You can set the signature algorithm
...
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 is null, then an enveloping XML signature is created. See also option parentNamespace
.
...
parentNamespace
...
String
...
null
...
Namespace of the parent of the Signature element. See 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 "". 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"), then you must provide the information about the ID attribute via a doctype definition contained in the input XML document.
...
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
...
Indicator 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
...
...
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 enveloped XML signature case. If null
then a unique value is generated. Available as of 2.12.2
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.
For creating detached XML signatures, see sub-chapter "Detached XML Signatures as Siblings of the Signed Elements".
Common Signing and Verifying Options
There are options which can be used for both endpoints, signer and verifier.
Wiki Markup |
---|
{div:class=confluenceTableSmall}{div} |
Name | Type | Default | Description |
---|---|---|---|
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 |
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 2.14.0. Classpath to the XML Schema file. If set then 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 sub-chapter "Detached XML Signatures as Siblings of the Signed Elements". |
Signing Options
The signer endpoint has the following options.
Wiki Markup |
---|
{div:class=confluenceTableSmall}{div} |
Name | Type | Default | Description |
---|---|---|---|
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 | Indicator whether a Reference element refering the KeyInfo element provided by the key accessor should be added to the XML signature. |
signatureAlgorithm | String | 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: |
Verifying Options
The verifier endpoint has the following options.
Wiki Markup |
---|
{div:class=confluenceTableSmall}{div} |
Name | Type | Default | Description |
---|---|---|---|
keySelector | null | Provides the key for validating the XML signature. There is an example implementation which uses a keystore, see DefaultKeySelector. | |
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 | Handles the different validation failed situations. The default implementation throws specific exceptions for the different situations (All exceptions have the package name | ||
xmlSignature2Message | 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 | String | "Default" | Determines the type of the search of the output node. See option |
outputNodeSearch | Object | null | Search value of the output node search. The type depends on the search type. For the default search implementation |
removeSignatureElements | Boolean | Boolean.FALSE | Indicator for removing Signature elements in the output message in the enveloped XML signature case. Used in the |
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
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 is null, then an enveloping XML signature is created. See also option |
parentNamespace | String | null | Namespace of the parent of the Signature element. See option |
canonicalizationMethod | 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 |
prefixForXmlSignatureNamespace | String |
| Prefix for the XML signature namespace. If |
contentReferenceUri | String | see description | The URI of the reference to the signed content (in-message body). If |
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 | Indicator 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 |
plainTextEncoding | String | null | Only used when the option |
properties | 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 |
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". |
Verifying Options
The verifier endpoint has the following options.
Wiki Markup |
---|
{div:class=confluenceTableSmall}{div} |
Name | Type | Default | Description |
---|---|---|---|
keySelector | null | Provides the key for validating the XML signature. There is an example implementation which uses a keystore, see DefaultKeySelector. | |
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 | Handles the different validation failed situations. The default implementation throws specific exceptions for the different situations (All exceptions have the package name | ||
xmlSignature2Message | 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 | String | "Default" | Determines the type of the search of the output node. See option |
outputNodeSearch | Object | null | Search value of the output node search. The type depends on the search type. For the default search implementation |
removeSignatureElements | Boolean | Boolean.FALSE | Indicator for removing Signature elements in the output message in the enveloped XML signature case. Used in the |
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
Code Block |
---|
<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
Code Block |
---|
<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.
Code Block | ||||
---|---|---|---|---|
| ||||
<?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
| ||||
Code Block | ||||
<Signature> <SignedInfo> <Reference URI="#object"/> <!-- further references possible but they must not point to an Object or Manifest containing an object reference --> ... </SignedInfo> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> <Object Id="object"> <ds:SignatureMethod <!-- contains one XML element which is extracted to the message body --> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Object> <!-- further object elements possible which are not referenced--<ds:Reference URI="#IDforC"> ... (<KeyInfo>)? </Signature> |
or the structure
Code Block |
---|
... <Signature> <SignedInfo> <Reference URI="#manifest"/></ds:Reference> <!-- further references </ds:SignedInfo> are possible but they must not point to an Object or other manifest containing an object reference --> <ds:SignatureValue>aUDFmiG71</ds:SignatureValue> </ds:Signature> ... </B> </SignedInfo>test> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"Id="_6b02fb8a-30df-42c6-ba25-76eba02c8214"> <Object > <ds:SignedInfo> <Manifest Id="manifest"> <ds:CanonicalizationMethod <Reference URI=#objectAlgorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /> </Manifest> <ds:SignatureMethod </Objet> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> <Object Id <ds:Reference URI="object#IDforA"> <!-- contains the DOM node which is extracted to the message body --> ... </ds:Reference> </Object> <!-- further object elements possible which are not referenced --> ... (<KeyInfo>)? </Signature> /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".