Add WS-Addressing Assertion

The Add WS-Addressing assertion is used to add WS-Addressing elements to a target message and optionally sign them.
gateway90
The
Add WS-Addressing
assertion is used to add WS-Addressing elements to a target message and optionally sign them.
The WS-Addressing elements configured in this assertion's properties are added to the SOAP header of the target message. If any WS-Addressing element to be added to the target message already exists, the existing element will be removed and a new element will be added. Any existing WS-Addressing elements in the SOAP message header will not be modified unless they are overwritten by an element configured in this assertion.
To learn about selecting the target message for this assertion, see Select a Target Message.
Context Variables Created by This Assertion
The Add WS Addressing assertion sets the following context variables. The default
<prefix>
is "wsa" and can be changed in the assertion properties.
<prefix>
.action
<prefix>
.messageId
Where:
  • <prefix>.action contains the value of the
    wsa:Action
    value resolved at runtime
  • <prefix>
    .messageId contains the message identifier resolved at runtime
The <prefix>.action context variable can be used in routing assertions to ensure that any outgoing SOAPAction or Content-Type action parameter matches any WS-Addressing Action property value in the message being routed.
Applying the WS-Addressing Elements
If the target message for this assertion is the request or a context variable, you need to add the Add or Remove WS-Security assertion after the Add WS-Addressing assertion in the policy for the WS-Addressing elements to be applied:
Request: Add WS-Addressing Request: Apply WS-Security
The Add or Remove WS-Security assertion is not required if the target is the response message.
Signing the WS-Addressing Elements
To sign the WS-Addressing elements, use either of the following assertions:
  • Configure WS-Security Decoration Assertion, with [
    Sign WS-Addressing Headers
    ] selected in the [
    Signing
    ] tab
  • Sign Element Assertion, which is designed to sign any element present in a message
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. When adding the assertion, the
    Add WS-Addressing Properties
    automatically appear; when modifying the assertion, right-click
    <target>:
    Add WS-Addressing
    in the policy window and select
    Add WS-Addressing Properties
    or double-click the assertion in the policy window. The assertion properties are displayed.
  3. Configure the properties as described in the table above. Note the following tips:
    • You may enter context variables of type String in any of the fields. 
    • For fields with a drop-down list, you are free to enter your own value if a suitable value does not appear in the list. Note that any value you enter will not appear in the drop-down list (i.e., you must manually enter that value again in the future if you wish to use it).
      Setting
      Description
      WS-Addressing Namespace
      From the drop-down list, select the WS-Addressing namespace to use or enter your own namespace.
      Action
      Specify how to obtain the
      wsa:Action
      value by selecting a strategy from the drop-down list.
      The wsa:Action
      value is placed in the context variable ${
      <prefix>
      .action}.
      • Obtain from target message:
        Select this option to first check the SOAPAction header for the Action value. If not, found, try the action Content Type parameter next; for example:
        content-type=*;action=...
      • Explicit from WSDL (Input):
        Select this option to first search for a
        wsaw:Action
        attribute on the
        wsdl:input
        element (child of
        wsdl:portType
        ->
        wsdl:operation
        ) from the WSDL. If not found, try searching for a
        soap:operation
        SOAPAction attribute from the WSDL next.
      • Explicit from WSDL (Output):
        Select this option to search for a
        wsaw:Action
        attribute on the
        wsdl:output
        element (child of
        wsdl:portType
        ->
        wsdl:operation
        ) from the WSDL. Unlike the option above, this option does not fall back onto the
        soap:operation
        SOAPAction.
      The
      wsa:Action
      is a required element. If no value for SOAPAction is found, then the assertion will fail.
      If you would like to employ more than one strategy to obtain the
      wsa:Action
      value, then add multiple instances of the assertion to the policy.
      MessageID
      Optionally enter a message identifier or select "<
      auto
      >" to have the system automatically generate a unique message ID. If left blank, the message ID will not be included in the SOAP header.
      The message ID is made available in the context variable ${
      <prefix>
      .messageId}.
      To
      Optionally enter the URI of the endpoint of the message. If left blank, the endpoint will not be included in the SOAP header
      From
      Optionally enter the URI of the endpoint from which the message originated. If left blank, the originating endpoint will not be included in the SOAP header
      ReplyTo Address
      Optionally enter the URI of the endpoint to which replies for the request message should be sent. If left blank, the ReplyTo address will not be included in the SOAP header
      FaultTo Address
      Optionally enter the URI of the endpoint to which fault messages should be sent. If left blank, the FaultTo address will not be included in the SOAP header
      RelatesTo MessageID
      Optionally specify the ID of a related message. The only relationship type currently supported is "Reply", with the value being
      http://www.w3.org/2005/08/addressing/reply
      . If left blank, the RelatesTo Message ID will not be included in the SOAP header
      Variable Prefix
      Enter a prefix that will be added to the context variables created by this assertion. This prefix will ensure uniqueness and will prevent the variables from overwriting each other when multiple instances of this assertion appear in a policy.
      The default prefix is
      wsa
      .
      For an explanation of the validation messages displayed, see Context Variable Validation.
  4. Click [
    OK
    ]
     
    when done.