(Non-SOAP) Sign XML Element Assertion

The (Non-SOAP) Sign XML Element assertion is used to immediately sign one or more elements in an XML message (either request, response, or a message context variable).
The (Non-SOAP) Sign XML Element assertion is used to immediately sign one or more elements in an XML message (either request, response, or a message context variable).
This assertion is designed only for messages not contained within a SOAP envelope.
This assertion should be used only by advanced users who have a specific need to sign XML elements outside of a SOAP envelope. If working with a SOAP document, use the Sign Element Assertion.
To learn about selecting the target message for this assertion, see Select a Target Message.
To learn more about selecting a private key for this assertion, see Select a Custom Private Key.
Sign Element Versus Immediate Sign XML Element
The (Non-SOAP) Sign XML Element assertion is designed to sign XML elements that are not within a SOAP message. This signing occurs immediately and the signature is inserted into the contents of the XML element.
By comparison, the Sign Element Assertion is used to sign elements within a SOAP message. This signing is scheduled in advance and conforms to WS-Security standards. The signature is added to the message's security header; the element itself is untouched.
Using the Assertion
  1. Do one of the following:
    • To add the assertion to the Policy Development window, see Add an Assertion.
    • To change the configuration of an existing assertion, proceed to step 2 below.
  2. Right-click <
    >: (
    Non-SOAP) Sign XML Element [XPath]
    in the policy window and select
    (Non-SOAP) XML Element Signature Properties
    or double-click the assertion in the policy window. The assertion properties are displayed.
  3. Configure the properties as follows:
    Edit XPath
    Click [
    Edit XPath
    ] to specify the element(s) to sign. For more information, see Select an XPath.
    Note that only elements can be signed. One Signature element is created per element being signed. The Signature is added as the last child of the element being signed; the Signature always uses the Enveloped transform and always includes the entire signing certificate in the KeyInfo as X509Data.
    Target URI Reference
    The signature reference requires an ID for the target element. Indicate how the
    Layer7 API Gateway
    should determine the ID:
    • Automatic
      : Select this to instruct the
      Layer7 API Gateway
      to look for an existing ID based on a built-in list of possible attribute names. If one is found, then its value is used. If one is not found, the
      Layer7 API Gateway
      will add an 'Id' attribute to the element being signed, with a randomly generated ID value, and references that.
      Having a new attribute 'Id' added may cause some difficulties if the schema of the signed element does not allow an 'Id' attribute. If this is the case, then enter a specific ID attribute name instead.
    • Specify ID Attribute Name
      : Select this option to manually specify the name of the ID attribute to use. If you choose this option, the
      Layer7 API Gateway
      will no longer recognize the built-in list of names. Instead, it will use the specified attribute value if it already exists on the target element and will generate a new one if it doesn't exist.
    Enter the name as a string value in one of the following formats:
      • NAME (e.g., abc)
      • PREFIX:NAME (e.g., abc:xyz)
      • {URI}NAME (e.g., {urn:issn:1535-3613}abc)
        (e.g., {urn:issn:1535-3613}abc:xyz)
    If a URI is specified, they must be absolute. Relative URIs cannot be used in signatures.
    If a prefix is specified, it may not necessarily be used. The
    Layer7 API Gateway
    will first attempt to reuse an existing namespace declaration for the namespace URI, if one exists, regardless of its prefix. If the
    Layer7 API Gateway
    needs to add a new namespace declaration, it will attempt to use the requested prefix if it is available. However if the requested prefix is already used in a different namespace URI, the
    Layer7 API Gateway
    will substitute a different prefix instead.
    Signature Location
    Specify where the signature should be located:
    • Add one Signature to...
      : Select this option to add a signature to each signed element. Choose where the signature should be added using the drop-down list: as the first or last child of the signed element.
    • Create detached signature and...
      : Select this option to create a detached signature which can later be added to the same or different document. A detached signature is a single signature that covers all elements matching the XPath of the elements to sign. It is placed in the context variable that you specify here and is not added to the document.
    • Include Enveloped transform
      : When creating a detached signature, select this check box to optionally include the Enveloped transform. Do this if the detached signature will be manually added to the document as a descendent of one of the signed elements.
    Signature Type
    Specify the hash algorithm to use for the Signature Digest or Reference Digest.
    • Signature Digest
      : By default, an appropriate signature digest will be selected based on the signing key size and the current value of the wss.decorator.digsig.messagedigest cluster property. If you wish to use a specific digest, select it from the drop-down list.
    • Reference Digest
      : By default, references will be created using the same digest algorithm as the signature digest. If you wish them to use a specific digest instead, select it from the drop-down list.
  4. Click [
    ] when done.