# XML Signature Generation

## Contents
Overview Signing Key What to Sign Where to Place Signature Additional Algorithm Suite Options

## Overview
The Enterprise Gateway can sign both SOAP and non-SOAP XML messages. Attachments to the message can also be signed. The resultant XML Signature is inserted into the message for consumption by a downstream Web Service. At the Web Service, the signature can be used to authenticate the message sender and/or verify the integrity of the message. Enter a name for the filter in the Name field. The Signature and Advanced top-level tabs contain the following tabs, which can be used to configure various aspects of the generated XML Signature.
## Signing Key
It is possible to use either a symmetric or an asymmetric key to sign the message content. Select the appropriate radio button and configure the fields on the corresponding tab. Asymmetric Key With an asymmetric signature, the signatory's private key (from a public-private key pair) is used to sign the message. The corresponding public key is then used to verify the signature. The following fields are available for configuration on this tab: Key in Store: To use a signing key from the Certificate Store, check the Key in Store radio button and then click the Signing Key button. Select a certificate that has the required signing key associated with it. The signing key can also be stored on a HSM (Hardware Security Module). Please refer to the Certificate Store help page for more information on storing signing keys. The Distinguished Name of the selected certificate will appear in the `X509SubjectName` element of the XML Signature as follows:
    <dsig:X509SubjectName>
       CN=Sample,OU=R&amp;D,O=Company Ltd.,L=Dublin 4,ST=Dublin,C=IE
    </dsig:X509SubjectName>
Key in Message Attribute: Alternatively, the signing key may have already have been used by another filter and stored in a message attribute. In order to reuse this key, you can select the Key in Message Attribute radio button and enter the name of the attribute in the field provided. Symmetric Key With a symmetric signature, the same key is used to sign and verify the message. Typically the client generates the symmetric key and uses it to sign the message. The key must then be transmitted to the recipient so that they can verify the signature. It would be unsafe to transmit an unprotected key along with the message so it is usually encrypted (or wrapped) with the recipient's public key. The key can then be decrypted with the recipient's private key and can then be used to verify the signature. The following configuration options are available on this screen: Generate Symmetric Key: Select this option if you want this filter to generate a symmetric key. Symmetric Key in Message Attribute: Alternatively, if you have already generated a symmetric key using a different filter (e.g. an Encryption filter) and stored it in a message attribute, you can select this radio button and enter the name of the message attribute in the field provided. Include Encrypted Symmetric Key in Message: As described earlier, the symmetric key is typically encrypted for the recipient and included in the message. However, it is possible that the initiator and recipient of the transaction have agreed on a symmetric key using some out-of-bounds mechanism. In this case, it is not necessary to include the key in the message. However, the default option is to include the encrypted symmetric key in the message. The <KeyInfo> section of the Signature will point to the <EncryptedKey>. Encrypt with Key in Store: Select this option to encrypt the symmetric key with a public key from the Certificate Store. Click the Signing Key button and then select the certificate that contains the public key of the recipient. By encrypting the symmetric key with this public key, you are ensuring that only the recipient that has access to the corresponding private key will be able to decrypt the encrypted symmetric key. Encrypt with Key in Message Attribute: You can also use a key stored in a message attribute to encrypt (or wrap) the symmetric key. Select this radio button and enter the name of the message attribute that contains the public key you want to use to encrypt the symmetric key with. Use Derived Key: A `<wssc:DerivedKeyToken>` token can be used to derive a symmetric key from the original symmetric key held in and `<enc:EncryptedKey>`. The derived symmetric key is then used to actually sign the message, as opposed to the original symmetric key. It must be derived again during the verification process using the parameters in the `<wssc:DerivedKeyToken>`. One of these parameters is the symmetric key held in `<enc:EncryptedKey>`. The following example shows the use of a derived key:
    <enc:EncryptedKey Id="Id-0000010b8b0415dc-0000000000000000">
      <enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
      <dsig:KeyInfo>
           ...
      </dsig:KeyInfo>
      <enc:CipherData>
    </enc:EncryptedKey>

    <wssc:DerivedKeyToken wsu:Id="Id-0000010bd2b8eca1-0000000000000017"
          Algorithm="http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1">
      <wsse:SecurityTokenReference wsu:Id="Id-0000010bd2b8ed5d-0000000000000018">
        <wsse:Reference URI="#Id Id-0000010b8b0415dc-0000000000000000"
        ValueType="..../oasis-wss-soap-message-security-1.1#EncryptedKey"/>
      </wsse:SecurityTokenReference>
      <wssc:Generation>0</wssc:Generation>
      <wssc:Length>32</wssc:Length>
      <wssc:Label>WS-SecureConverstaionWS-SecureConverstaion</wssc:Label>
      <wssc:Nonce>h9TTWKRylCOz87+mc1/7Pg==</wssc:Nonce>
    </wssc:DerivedKeyToken>

    <dsig:Signature Id="Id-0000010b8b0415dc-0000000000000004">
      <dsig:SignedInfo>
        <dsig:CanonicalizationMethod
              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <dsig:SignatureMethod
            Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/>
        <dsig:Reference>...</dsig:Reference>
      </dsig:SignedInfo>
      <dsig:SignatureValue>...dsig:SignatureValue>
      <dsig:KeyInfo>
        <wsse:SecurityTokenReference wsu:Id="Id-0000010b8b0415dc-0000000000000006">
          <wsse:Reference
              URI="# Id-0000010bd2b8eca1-0000000000000017"
              ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk"/>
        </wsse:SecurityTokenReference>
      </dsig:KeyInfo>
    </dsig:Signature>
Symmetric Key Length: This option allows the user to specify the length of the key to use when performing symmetric key signatures. It is important to realize that the longer the key, the stronger the encryption. Key Info This tab configures how the <KeyInfo> block of the generated XML Signature will appear. Configure the following fields on this tab: Do Not Include KeyInfo Section: This option allows you to omit all information about the signatory's certificate from the signature. In other words, the `KeyInfo` element is omitted from the signature. This is useful where a downstream Web Service uses an alternative method of authenticating the signatory, and wishes to use the signature for the sole purpose of verifying the integrity of the message. In such cases, adding certificate information to the message may be regarded as an unnecessary overhead. Include Certificate: This is the default option which places the signatory's certificate inside the XML Signature itself. The following example, shows an example of an XML Signature which has been created using this option:
    <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
      ...
     <dsig:KeyInfo>
      <dsig:X509Data>
       <dsig:X509SubjectName>CN=Sample...</dsig:X509SubjectName>
       <dsig:X509Certificate>
           MIIEZDCCA0yg
           ....
           RNp9aKD1fEQgJ
       </dsig:X509Certificate>
      </dsig:X509Data>
     </dsig:KeyInfo>
    </dsig:Signature>
Expand Public Key: The details of the signatory's public key are inserted into a `KeyValue` block. The `KeyValue` block is only inserted when this option is checked.
    <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
       ...
     <dsig:KeyInfo>
      <dsig:X509Data>
       <dsig:X509SubjectName>CN=Sample...</dsig:X509SubjectName>
       <dsig:X509Certificate>
          MIIE ....... EQgJ
       </dsig:X509Certificate>
      </dsig:X509Data>
      <dsig:KeyValue>
       <dsig:RSAKeyValue>
        <dsig:Modulus>
           AMfb2tT53GmMiD
           ...
           NmrNht7iy18=
        </dsig:Modulus>
        <dsig:Exponent>AQAB</dsig:Exponent>
       </dsig:RSAKeyValue>
      </dsig:KeyValue>
     </dsig:KeyInfo>
    </dsig:Signature>
Include Distinguished Name: If this checkbox is checked, the Distinguished Name of the signatory's X.509 certificate will be inserted in an `<X509SubjectName>` element as shown in the following example:
    <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
      ...
     <dsig:KeyInfo>
      <dsig:X509Data>
       <dsig:X509SubjectName>CN=Sample,C=IE...</dsig:X509SubjectName>
       <dsig:X509Certificate>
           MIIEZDCCA0yg
           ....
           RNp9aKD1fEQgJ
       </dsig:X509Certificate>
      </dsig:X509Data>
     </dsig:KeyInfo>
    </dsig:Signature>
Include Key Name: This option allows you insert a key identifier, or `KeyName`, to allow the recipient to identify the signatory. Enter an appropriate value for the `KeyName` in the Value field. Typical values include Distinguished Names (DName) from X.509 certificates, key IDs, or email addresses. Specify whether the specified value is a Text value of a Distinguished name attribute by checking the appropriate radio button.
    <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
       ...
     <dsig:KeyInfo>
      <dsig:KeyName>test@oracle.com</dsig:KeyName>
     </dsig:KeyInfo>
    </dsig:Signature>
Put Certificate in an Attachment: The Enterprise Gateway supports SOAP messages with attachments. By selecting this option, you can save the signatory's certificate to the file specified in the input field. This file can then be sent along with the SOAP message as a SOAP attachment. From previous examples, it is clear that the user's certificate is usually placed inside a `KeyInfo` element. However, in this example, the certificate is actually contained within an attachment, and not within the XML Signature itself. Clearly, we need a way to reference the certificate from the XML Signature, so that validating applications can process the signature correctly. This is the role of the `SecuriyTokenReference` block. The `SecurityTokenReference` block provides a generic way for applications to retrieve security tokens in cases where these tokens are not contained within the SOAP message. The name of the security token is specified in the `URI` attribute of the `Reference` element.
    <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
       ...
     <dsig:KeyInfo>
      <wsse:SecurityTokenReference xmlns:wsse="http://schemas.xmlsoap.org/ws/...">
       <wsse:Reference URI="c:\myCertificate.txt"/>
      </wsse:SecurityTokenReference>
     </dsig:KeyInfo>
    </dsig:Signature>
When the message is actually sent, the certificate attachment will be given a "Content-Id" corresponding to the `URI` attribute of the `Reference` element. The following example shows what the complete multipart MIME SOAP message looks like as it is sent over the wire. It should help illustrate how the `Reference` element actually refers to the "Content-ID" of the attachment:
    POST /adoWebSvc.asmx HTTP/1.0
    Content-Length: 3790
    User-Agent: Enterprise Gateway
    Accept-Language: en
    Content-Type: multipart/related; type="text/xml";
                  boundary="----=Multipart-SOAP-boundary"

    ------=Multipart-SOAP-boundary
    Content-Id: soap-envelope
    Content-Type: text/xml; charset="utf-8";
    SOAPAction=getQuote

    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
       ...
     <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
        ...
      <dsig:KeyInfo>
       <ws:SecurityTokenReference xmlns:ws="http://schemas.xmlsoap.org/ws/...">
        <ws:Reference URI="c:\myCertificate.txt"/>
       </ws:SecurityTokenReference>
      </dsig:KeyInfo>
     </dsig:Signature>
        ...
    </s:Envelope>

    ------=Multipart-SOAP-boundary
    Content-Id: c:\myCertificate.txt
    Content-Type: text/plain; charset="US-ASCII"

    MIIEZDCCA0ygAwIBAgIBAzANBgkqhki
    ....
    7uFveG0eL0zBwZ5qwLRNp9aKD1fEQgJ
    ------=Multipart-SOAP-boundary-
Security Token Reference: A `<wsse:SecurityTokenReference>` element can be used to point to the security token used in the generation of the signature. Select this option if you wish to use this element. The type of the reference must be selected from the Reference Type dropdown. The `<wsse:SecurityTokenReference>`, (within the `<dsig:KeyInfo>`), may contain a `<wsse:Embedded>` security token. Alternatively, the `<wsse:SecurityTokenReference>`, (within the `<dsig:KeyInfo>`), may refer to a certificate via a `<dsig:X509Data>`. Select the appropriate button, Embed or Refer, depending on whether you want to use an embedded security token or a referred one. You can make sure to include a <BinarySecurityToken> (BST) that contains the certificate used to wrap the symmetric key in the message by selecting the Include BinarySecurityToken option. The BST will be inserted into the WS-Security header regardless of the type of Security Token Reference selected from the dropdown. It is important to note that when using the "Kerberos Token Profile" standard and the Enterprise Gateway is acting as the initiator of a secure transaction, it can use Kerberos session keys to sign a message. The KeyInfo must be configured to use a Security Token Reference with a ValueType of "GSS_Kerberosv5_AP_REQ". In this case, the Kerberos token is contained within a <BinarySecurityToken> within the message. If the Enterprise Gateway is acting as the recipient of a secure transaction, it can also use the Kerberos session keys to sign the message returned to the client. However, in this case, the KeyInfo must be configured to use a Security Token Reference with ValueType of "Kerberosv5_APREQSHA1". When this ValueType is selected, the Kerberos token is not contained within the message. The Security Token Reference contains a SHA1 digest of the original Kerberos token received from the client, which identifies the session keys to the client. Note that when using the "WS-Trust for SPENGO" standard, the Kerberos session keys are not used directly to sign messages since a security context with an associated symmetric key is negotiated. This symmetric key is shared by both client and service and can be used to sign messages on both sides.
## What to Sign
This tab is used to identify parts of the message that must be signed. Each signed part will be referenced from within the generated XML Signature. It is possible to use any combination of Node Locations, XPaths, XPath Predicates, and the nodes contained in a Message Attribute to specify what must be signed. Please refer to the Locate XML Nodes filter for more information on how to use these node selectors. It is important to consider the mechanisms available for referencing signed elements from within an XML Signature. With WSU IDs, an ID attribute is inserted into the root element of the nodeset that is to be signed. The XML Signature then references this ID to indicate to verifiers of the Signature the nodes that were signed. The use of WSU IDs is the default option since they are WS-I compliant. Alternatively, a generic ID attribute (that is not bound to the WSU namespace) can be used to dereference the data. The ID attribute is inserted into the top-level element of the nodeset that is to be signed. The generated XML Signature can then reference this ID to indicate what nodes were signed. When XPath transforms are used, an XPath expression that points to the root node of the nodeset that is signed will be inserted into the XML Signature. When attempting to verify the Signature, this XPath expression must be run on the message to retrieve the signed content. Use WSU IDs: Select this option to reference the signed data using a `wsu:Id` attribute. In this case, a `wsu:Id` attribute is inserted into the root node of the nodeset that is signed. This id is then referenced in the generated XML Signature as an indication of what nodes were signed. The following example shows the correlation:
    <soap:Envelope xmlns:soap="...">
      <soap:Header>
      <wsse:Security xmlns:wsse="...">
        <dsig:Signature xmlns:dsig="..." Id="Id-00000112e2c98df8-0000000000000004">
          <dsig:SignedInfo>
            <dsig:CanonicalizationMethod
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <dsig:SignatureMethod
                Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
            <dsig:Reference URI="#Id-00000112e2c98df8-0000000000000003">
              <dsig:Transforms>
                <dsig:Transform
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              </dsig:Transforms>
              <dsig:DigestMethod
                  Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
              <dsig:DigestValue>xChPoiWJJrrPZkbXN8FPB8S4U7w=</dsig:DigestValue>
            </dsig:Reference>
          </dsig:SignedInfo>
          <dsig:SignatureValue>KG4N .... /9dw==</dsig:SignatureValue>
          <dsig:KeyInfo Id="Id-00000112e2c98df8-0000000000000005">
            <dsig:X509Data>
              <dsig:X509Certificate>
                MIID ... ZiBQ==
              </dsig:X509Certificate>
            </dsig:X509Data>
          </dsig:KeyInfo>
        </dsig:Signature>
      </wsse:Security>
      </soap:Header>
       <soap:Body xmlns:wsu="..." wsu:Id="Id-00000112e2c98df8-0000000000000003">
      <vs:getProductInfo xmlns:vs="http://ww.oracle.com">
       <vs:Name>Enterprise Gateway</vs:Name>
       <vs:Version>11.1.1.5.0</vs:Version>
      </vs:getProductInfo>
     </s:Body>
    </s:Envelope>
In the above example, a `wsu:Id` attribute has been inserted into the `<soap:Body>` element. This `wsu:Id` attribute is then referenced by the `URI` attribute of the `<dsig:Reference>` element in the actual Signature. When the Signature is being verified, the value of the `URI` attribute can be used to locate the nodes that have been signed. Use IDs: Select this option in order to use generic IDs (that are not bound to the WSU namespace) to dereference the signed data. Under this schema, the `URI` attribute of the `<Reference>` points at an ID attribute, which is inserted into the top-level node of the nodeset that is signed. Take a look at the following example, noting how the ID specified in the Signature matches the ID attribute that has been inserted into the `<Body>` element, indicating that the Signature applies to the entire contents of the SOAP Body.
    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
      <soap:Header>
        <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
                    Id="Id-0000011a101b167c-0000000000000013">
          <dsig:SignedInfo>
            <dsig:CanonicalizationMethod
                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <dsig:SignatureMethod
                Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
            <dsig:Reference URI="#Id-0000011a101b167c-0000000000000012">
              <dsig:Transforms>
                <dsig:Transform
                    Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
              </dsig:Transforms>
              <dsig:DigestMethod
                  Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
              <dsig:DigestValue>JCy0JoyhVZYzmrLrl92nxfr1+zQ=</dsig:DigestValue>
            </dsig:Reference>
          </dsig:SignedInfo>
          <dsig:SignatureValue>......<dsig:SignatureValue>
          <dsig:KeyInfo Id="Id-0000011a101b167c-0000000000000014">
            <dsig:X509Data>
              <dsig:X509Certificate>......</dsig:X509Certificate>
            </dsig:X509Data>
          </dsig:KeyInfo>
        </dsig:Signature>
      </soap:Header>
     <soap:Body Id="Id-0000011a101b167c-0000000000000012">
      <product version="11.1.1.5.0">
        <name>Enterprise Gateway</name>
        <company>Oracle</company>
        <description>SOA Security and Management</description>
      </product>
     </soap:Body>
    </soap:Envelope>
Use SAML IDs for SAML Elements: This option is only relevant if a SAML assertion is required to be signed. If this option is checked and the signature is to cover a SAML assertion, an `AssertionID` attribute will be inserted into a SAML version 1.1 assertion, or an `ID` attribute will be inserted into a SAML version 2.0 assertion. The value of this attribute will then be referenced from within a <Reference> block of the XML Signature.
## Where to Place Signature
Append Signature to Root or SOAP Header: If the message is a SOAP message, the signature will be inserted into the SOAP `Header` element when this radio button is selected. The XML Signature will be inserted as an immediate child of the SOAP `Header` element. The following example shows a skeleton SOAP message which has been signed using this option:
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
     <s:Header>
      <ws:Security xmlns:ws="http://schemas.xmlsoap.org/..." s:actor="test">
       <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/..." id="Sample">
         ...
       </dsig:Signature>
      </ws:Security>
     </s:Header>
     <s:Body>
      ...
     </s:Body>
    </s:Envelope>
If, on the other hand, the message is just plain XML, the signature will be inserted as an immediate child of the root element of the XML message. The following example shows a non-SOAP XML message which has been signed using this option:
    <PurchaseOrder>
     <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" id="Sample">
      ...
     </dsig:Signature>

     <Items>
     ...
     </Items>
    </PurchaseOrder>
Place in WS-Security Element for SOAP Actor/Role: By selecting this option, the XML Signature will be inserted into the WS-Security element identified by the specified SOAP actor or role. A SOAP actor/role is simply a way of distinguishing a particular WS-Security block from others which may be present in the message. Actors belong to the SOAP 1.1 specification, but were replaced in SOAP 1.2 by roles. Conceptually, however, they are identical. Enter the name of the SOAP actor or role of the WS-Security block in the dropdown. The following SOAP message contains an XML Signature within a WS-Security block identified by the "test" actor:
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
     <s:Header>
      <ws:Security xmlns:ws="http://schemas.xmlsoap.org/..." s:actor="test">
       <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/..." id="Sample">
           ...
       </dsig:Signature>
      </ws:Security>
     </s:Header>
     <s:Body>
      ...
     </s:Body>
    </s:Envelope>
Use XPath Location: This option is useful in cases where the signature must be inserted into a non-SOAP XML message. In such cases, it is possible to insert the signature into a location pointed to by an XPath expression. Select or add an XPath expression in the field provided, and then specify whether the Enterprise Gateway should insert the signature before the location to which the XPath expression points, or append it to this location.
## Additional
The Additional tab allows you to select additional elements from the message that are to be signed. It is also possible to insert a WS-Security Timestamp into the XML Signature, if necessary. Additional Elements to Sign: The options here allow you to select other parts of the message that you may wish to sign. Sign KeyInfo Element of Signature: The <KeyInfo> block of the XML Signature can be signed to prevent people cut-and-pasting a different <KeyInfo> block into the message, which may point to some other key material, for example. Sign Timestamp: As stated earlier, timestamps are used to prevent replay attacks. However, to guarantee the end-to-end integrity of the timestamp, it is necessary to sign it. Note that this option is only enabled when you have elected to insert a Timestamp into the message using the relevant fields on the Timestamp Options panel below. Sign Attachments: In addition to signing some or all of the contents of the SOAP message, it is also possible to sign attachments to the SOAP message. To sign all attachments, check the Include Attachments checkbox. A signed attachment is referenced in an XML Signature using the Content-Id or cid of the attachment. The `URI` attribute of the `Reference` element corresponds to this Content-Id. The following example shows how an XML Signature refers to a sample attachment. It shows the wire format of the message and its attachment as they are sent to the destination Web Service. Multiple attachments will result in successive `Reference` elements.
    POST /myAttachments HTTP/1.0
    Content-Length: 1000
    User-Agent: Enterprise Gateway
    Accept-Language: en
    Content-Type: multipart/related; type="text/xml";
                  boundary="----=Multipart-SOAP-boundary"

    ------=Multipart-SOAP-boundary
    Content-Id: soap-envelope
    SOAPAction: none
    Content-Type: text/xml; charset="utf-8"

    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
     <s:Header>
      <dsig:Signature id="Sample" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
       <dsig:SignedInfo>
        <dsig:CanonicalizationMethod
            Algorithm="http://www.w3.org/2001/10/xml-exc-c14n"/>
        <dsig:SignatureMethod
            Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
        <dsig:Reference URI="cid:moredata.txt">...</dsig:Reference>
       </dsig:SignedInfo>
      </dsig:Signature>
     </s:Header>
     <s:Body>
        ...
     </s:Body>
    </s:Envelope>

    ------=Multipart-SOAP-boundary
    Content-Id: moredata.txt
    Content-Type: text/plain; charset="UTF-8"

    Some more data.
    ------=Multipart-SOAP-boundary--
Transform: This dropdown is only available when you have selected the Sign Attachments box above. It determines the transform used to reference the signed attachments. Timestamp Options: It is possible to insert a timestamp into the message to indicate when exactly the signature was generated. Consumers of the signature can then validate the signature to ensure that it is not of date. The following options are available: No Timestamp: No timestamp will be inserted into the signature. Embed in WSSE Security: The "wsu:Timestamp" will be inserted into a "wsse:Security" block. The Security block is identified by the SOAP actor/role specified on the Signature tab. Embed in Signature Property: The "wsu:Timestamp" will be placed inside a signature property element in the "dsig:Signature". The Expires In fields allow the user to optionally specify the "wsu:Expires" for the "wsu:Timestamp". If all fields are left at "0", no "wsu:Expires" element will be placed inside the "wsu:Timestamp". The following examples shows a "wsu:Timestamp" that has been inserted into a "wsse:Security" block:
    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
     <s:Header>
       <wsse:Security>
         <wsu:Timestamp wsu:Id="Id-0000011294a0311e-000000000000003d">
          <wsu:Created>2007-05-16T11:22:45Z</wsu:Created>
          <wsu:Expires>2007-05-23T11:22:45Z</wsu:Expires>
        </wsu:Timestamp>
        <dsig:Signature ...>
        ...
        </dsig:Signature ...>
       </wsse:Security>
     </s:Header>
     <s:Body>
        ...
     </s:Body>
    </s:Envelope>
## Algorithm Suite
The fields on this tab determine the combination of cryptographic algorithms and ciphers that are used to sign the message parts. Algorithm Suite: WS-Security Policy defines a number of algorithm suites that group together a number of cryptographic algorithms. For example, a given algorithm suite will use specific algorithms for asymmetric signing, symmetric signing, asymmetric key wrap, and so on. Therefore, by specifying an algorithm suite, you are effectively selecting a whole suite of cryptographic algorithms to use. If you want to use a particular WS-Security Policy algorithm suite, you can select it here. The Signature Method, Key Wrap Algorithm, and Digest Method fields will then be automatically populated with the corresponding algorithms for that suite. Signature Method: The Signature Method field allows you to configure the method used to generate the signature. Various strengths of the HMAC-SHA1 algorithms are available from the dropdown. Key Wrap Algorithm: Select the algorithm to use to wrap (i.e. encrypt) the symmetric signing key. This option need only be configured when you are using a symmetric key to sign the message. Digest Algorithm: Select the digest algorithm to you to produce a cryptographic hash of the signed data.
## Options
Advanced Options: This section allows you to configure various advanced options on the generated XML Signature. The following fields can be configured on this tab: WS-Security Options: WSSE 1.1 defines a <SignatureConfirmation> element that can be used as proof that a particular XML Signature was processed. A recipient and verifier of an XML Signature must generate a <SignatureConfirmation> element for each piece of data that was signed (i.e. for each <Reference> in the XML Signature). A <SignatureConfirmation> element contains the hash of the signed data and must be signed by the recipient before returning it in the response to the initiator (i.e. the original signatory of the data). When the initiator receives the <SignatureConfirmation> elements in the response, it compares the hash with the hash of the data that it produced initially. If the hashes match, the initiator knows that the recipient has processed the same signature. Select the Initiator option here if the Enterprise Gateway is the initiator as outlined in the scenario above. The Enterprise Gateway will keep a record of the signed data and will compare it to the contents of the <SignatureConfirmation> elements returned from the recipient in the response message. Alternatively, if the Enterprise Gateway is acting as the recipient in this transaction, you can select the Responder radio button to instruct the Enterprise Gateway to generate the <SignatureConfirmation> elements and return them to the inititor. The signature confirmations will be added to the WS-Security header. Layout Type: Select the WS-Security Policy layout type that you want the XML Signature and any generated tokens to adhere to. This includes elements such as <Signature>, <BinarySecurityToken>, and <EncryptedKey>, which can all be generated as part of the signing process. Fail if No Nodes to Sign: Check this option if you want the filter to fail if it cannot find any nodes to sign as configured on the What to Sign tab. Add Inclusive Namespaces for Exclusive Canonicalization: It is possible to include information about the namespaces (and their associated prefixes) of signed elements in the signature itself. This ensures that namespaces that are in the same scope as the signed element, but not directly or "visibly" used by this element, are included in the signature. This ensures that the signature can be validated as a standalone entity outside of the context of the message from which it was extracted. It is also worth pointing out that the WS-I specification only permits the use of exclusive canonicalization in an XML Signature. The `<InclusiveNamespaces>` element is an attempt to take advantage of some of the behavior of inclusive canonicalization, while maintaining the simplicity of exclusive canonicalization. A PrefixList attribute is used to list the prefixes of in-scope, but not visibly used elements and attributes. The following example shows how the `PrefixList` attribute is used in practice:
    <soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope'>
     <soap:Header>
      <wsse:Security xmlns:wsse='http://docs.oasis-open.org/...'
                     xmlns:wsu='http://docs.oasis-open.org/...'>
       <wsse:BinarySecurityToken wsu:Id='SomeCert'
                                 ValueType="http://docs.oasis-open.org/...">
       lui+Jy4WYKGJW5xM3aHnLxOpGVIpzSg4V486hHFe7sH
       </wsse:BinarySecurityToken>
       <ds:Signature xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
        <ds:SignedInfo>
         <ds:CanonicalizationMethod
             Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
          <c14n:InclusiveNamespaces
              xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
              PrefixList='wsse wsu soap' />
         </ds:CanonicalizationMethod>
         <ds:SignatureMethod
              Algorithm='http://www.w3.org/2000/09/xmldsig#rsa-sha1'/>
         <ds:Reference URI=''>
          <ds:Transforms>
           <dsig:XPath xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
                       xmlns:m='http://example.org/ws'>
           //soap:Body/m:SomeElement
           </dsig:XPath>
           <ds:Transform Algorithm='http://www.w3.org/2001/10/xml-exc-c14n#'>
            <c14n:InclusiveNamespaces
                  xmlns:c14n='http://www.w3.org/2001/10/xml-exc-c14n#'
                  PrefixList='soap wsu test' />
           </ds:Transform>
          </ds:Transforms>
          <ds:DigestMethod Algorithm='http://www.w3.org/2000/09/xmldsig#sha1' />
          <ds:DigestValue>VEPKwzfPGOxh2OUpoK0bcl58jtU=</ds:DigestValue>
         </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>+diIuEyDpV7qxVoUOkb5rj61+Zs=</ds:SignatureValue>
        <ds:KeyInfo>
         <wsse:SecurityTokenReference>
          <wsse:Reference URI='#SomeCert' />
         </wsse:SecurityTokenReference>
        </ds:KeyInfo>
       </ds:Signature>
      </wsse:Security>
     </soap:Header>
     <soap:Body xmlns:wsu='http://docs.oasis-open.org/...'
                xmlns:test='http://www.test.com' wsu:Id='TheBody'>
      <m:SomeElement xmlns:m='http://example.org/ws' attr1='test:fdwfde' />
     </soap:Body>
    </soap:Envelope>
Indent: Select this method to ensure that the generated signature is properly indented. Create Enveloped Signature: By selecting this option, an enveloped XML Signature is generated. The following skeleton signed SOAP message shows the enveloped signature
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" id="Sample">
     <ds:SignedInfo>
      <ds:Reference URI="">
       <ds:Transforms>
        <ds:Transform
            Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
       </ds:Transforms>
      </ds:Reference>
     </ds:SignedInfo>
    </ds:Signature>
This indicates to the application validating the signature that the signature itself should not be included in the signed data. In other words, to validate the signature, the application must first strip out the signature. This is necessary in cases where the entire SOAP envelope has been signed, and the resulting signature has been inserted into the SOAP header. In this case, the signature is over a nodeset which has been altered (i.e. the Signature has been inserted), and so the signature will break. Insert CarriedKeyName for EncryptedKey: Check this option to include a <CarriedKeyName< element in the <EncryptedKey> block that is generated when using a symmetric signing key.