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:
- Authentication for the following tokens:
- Username tokens (requires a security profile to specify the external
security provider)
- X.509 certificates (requires the broker keystore and truststore,
or a security profile to specify the external security provider)
- SAML assertions, using SAML 1.1 or 2.0 pass-through (requires
a security profile to specify the external security provider)
- LTPA tokens, using LTPA pass-through (requires a security profile
to specify the external security provider)
- Asymmetric encryption (confidentiality) using X.509
certificates (requires the broker keystore and truststore)
- Symmetric encryption (confidentiality) using Kerberos
tokens (requires the host to be configured for Kerberos)
- Asymmetric signature (integrity) (requires the broker keystore
and truststore)
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
-
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.
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.
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.
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.