IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Policy sets

Policy sets and bindings define and configure your WS-Security and WS-RM requirements, supported by IBM® Integration Bus, for the SOAPInput, SOAPReply, SOAPRequest, SOAPAsyncRequest, and SOAPAsyncResponse nodes.

A policy set is a container for the WS-Security and WS-RM policy types.

A policy set binding is associated with a policy set and contains information that is specific to the environment and platform, such as information about keys.

Use policy sets and bindings to define the following items for both request and response SOAP messages:

Either the whole SOAP message body, or specific parts of the SOAP message header and body can be encrypted and signed.

You administer policy sets and bindings from IBM Integration Explorer, which can add, delete, display and edit policy sets and bindings. Any changes to policy sets or bindings in the toolkit are saved directly to the associated broker. You must stop and then restart the message flow for the new configuration information to take effect.

You can also export and import policy sets and bindings from a broker. Policy sets and their associated bindings must be saved and restored together.

Policy sets are associated with a message flow, a node or both in the Broker Archive editor. For convenience, you can specify settings for provider and consumer at the message flow level. The provider setting applies to all SOAPInput and SOAPReply nodes in the message flow. The consumer setting applies to all SOAPRequest, SOAPAsyncRequest, and SOAPAsyncResponse nodes. Individual policy set and binding assignments can be applied at the node level in the Broker Archive editor, and these take precedence over the flow-level provider and consumer settings. The default setting is none, meaning that no policy set and bindings are to be used.

Several nodes in the same message flow can refer to the same policy set and bindings. It is the responsibility of the administrator to ensure that the required policy sets are available to the broker at run time. An error is reported if the broker cannot find the associated policy set or bindings.

The rest of this topic describes some of the terms that you will meet when configuring policy sets and bindings.

Default policy set and bindings

When a broker is created, a default policy set and bindings are created called WSS10Default. This default contains a limited security policy which specifies that a Username token is present in request messages (inbound) to SOAPInput nodes in the associated message flow. A default WS-RM policy set called WSRMDefault is also created.

The default policy set binding refers to the default WSS10Default policy set, but not to WSRMDefault. They are not editable.

Consumer and provider nodes

Nodes are either consumers or providers.
Consumer nodes
  • SOAPRequest
  • SOAPAsyncRequest
  • SOAPAsyncResponse
Provider nodes
  • SOAPInput
  • SOAPReply

Request and response

Request and response is a message exchange pattern (MEP). It describes a client that sends a SOAP Request message to a Web services server, which in turn sends a Response SOAP message back to the client. The Request message is always the SOAP message from the client to the server, and the Response message is always the SOAP message reply from server to the client. The following table describes this pattern in relation to the IBM Integration Bus SOAP nodes:
Node Broker viewpoint Request Response
SOAPInput SOAP message inbound Inbound message Not applicable
SOAPReply SOAP message outbound Not applicable Outbound message
SOAPRequest SOAP message outbound followed by a SOAP message inbound Outbound message Inbound message
SOAPAsyncRequest SOAP message outbound Outbound message Not applicable
SOAPAsyncResponse SOAP message inbound Not applicable Inbound message

Initiator and recipient

Initiator and recipient are roles defined in the exchange of SOAP messages.
Initiator
The role that sends the initial message in a message exchange.
Recipient
The targeted role to process the initial message in a message exchange.
The following table describes these roles in relation to the SOAP nodes:
Node Broker viewpoint Initiator Recipient
SOAPInput SOAP message inbound External client sending SOAP message to the broker. SOAPInput node
SOAPReply SOAP message outbound External client that sent the original SOAP message to the broker. SOAPReply node
SOAPRequest (outbound) SOAP message outbound followed by a SOAP message inbound SOAPRequest node External provider receiving the SOAP message
SOAPRequest (inbound) SOAP message outbound followed by a SOAP message inbound SOAPRequest node External provider receiving the SOAP message
SOAPAsyncRequest SOAP message outbound SOAPAsyncRequest node External provider receiving the SOAP message
SOAPAsyncResponse SOAP message inbound SOAPAsyncRequest node External provider receiving the SOAP message

SOAPInput and SOAPReply nodes

In this diagram, the broker acts as recipient. A SOAPInput node receives a message from a client (initiator). A SOAPReply node replies. Inbound and outbound messages are signed and encrypted.
This graphic shows the interactions between message broker and client when the SOAP Input and SOAP Reply nodes are used.
In the request:
  • The initiator uses the broker's public encryption token to encrypt the message, and its own private signature token to sign it.
  • The broker uses its own private encryption token to decrypt the message, and the initiator's public signature token to verify the signature.
In the response:
  • The broker uses the initiator's public encryption token to encrypt the message, and its own private signature token to sign the message.
  • The initiator uses its own private encryption token to decrypt the message, and the broker's public signature token to verify the signature.

SOAPRequest node

This diagram shows the broker acting as an initiator. It uses the SOAPRequest node to make a synchronous request to an external provider (the recipient). Inbound and outbound messages are signed and encrypted. Use of tokens is similar to the example of the asynchronous SOAP nodes, shown earlier.
This graphic shows the interactions between message broker and server when the SOAP Request node is used.
In the request:
  • The broker uses the recipient's public encryption token to encrypt the message, and its own private signature token to sign the message.
  • The recipient uses its own private encryption token to decrypt the message, and the broker's public signature token to verify the signature.
In the response:
  • The recipient uses the broker's public encryption token to encrypt the message, and its own private signature token to sign the message.
  • The broker uses its own private encryption token to decrypt the message, and the initiator's public signature token to verify the signature.

Asynchronous SOAP nodes

This diagram shows the broker acting as an initiator. It uses the asynchronous SOAP nodes to make a request to an external provider (the recipient). Inbound and outbound messages are signed and encrypted.

This graphic shows the interactions between message broker and server when the asynchronous SOAP nodes are used.

In the request:
  • The broker uses the recipient's public encryption token to encrypt the message, and its own private signature token to sign the message.
  • The recipient uses its own private encryption token to decrypt the message, and the broker's public signature token to verify the signature.
In the response:
  • The recipient uses the broker's public encryption token to encrypt the message, and its own private signature token to sign the message.
  • The broker uses its own private encryption token to decrypt the message, and the initiator's public signature token to verify the signature.

ac60110_.htm | Last updated Friday, 21 July 2017