Invoking message flow security using a SecurityPEP node
You can invoke the message flow
security manager at any point in a message flow, between an input
node and an output or request node, by using a SecurityPEP node.
The following diagram shows an example message flow and gives an
overview of the sequence of events that occur when an input message
is received by an input node that is not security enabled (or that
has no associated security profile) and is later processed by a SecurityPEP node in the message
flow:

The following steps explain the sequence of events that
occur when a message arrives at an input node that is not security
enabled (or that has no associated security profile). The numbers
correspond to those in the preceding diagram:
- You can use a SecurityPEP node
at any point in a message flow between an input and an output or request
node. The SecurityPEP node
enables security to be applied in a message flow in the following
situations:
- When the message flow input node is not security enabled (for
example, FileInput, TCPIPClientInput, SAPInput, and JMSInput nodes).
- When the message flow input node is security enabled and might
be configured to perform authentication operations, but the message
flow is required to perform some routing or filtering before the business
function being invoked is known; as a result, authorization needs
to be performed later in the message flow logic.
- When the message flow includes multiple output or request nodes,
which require a specific identity mapping to be performed before each
node, to obtain the appropriate security tokens for propagation.
The message tree that is propagated into the SecurityPEP node includes the
properties tree identity fields. These fields are empty, unless a
security enabled input node (or a prior SecurityPEP node) has already
extracted identity tokens, and possibly performed some security operations.
- When a message arrives at a SecurityPEP, the presence of
a security profile associated with the node indicates whether message flow security
is configured. The integration node's security manager
is called to read the profile, which specifies the combination of propagation,
authentication, authorization, and mapping to be performed with the identity of the
message. It also specifies the external security provider (also known as the Policy
Decision Point or PDP) to be used.
You can create security profiles by using the
mqsicreateconfigurableservice command. You
then use the BAR editor to configure the security
profile on either an individual node or the whole message flow. If you associate the
security profile with the message flow, the security profile applies to all security
enabled input and output and SecurityPEP
nodes in the message flow. However, a security profile that is associated with an
individual node takes precedence over a security profile that is associate with the
message flow. Predefined security profiles are provided for setting identity
propagation and for explicitly setting no security on a node.
- If a security profile is associated with the SecurityPEP node or message
flow, the node extracts the identity information from the message
tree based on the node configuration and sets the Source Identity
elements in the Properties folder. If the node sets a token type of Current
token, the existing identity tokens in the Mapped Identity
properties fields are used (if they exists); if there are no identity
tokens in the Mapped Identity properties fields, the tokens in the
Source Identity properties fields are used. If the security tokens
cannot be successfully extracted, a security exception is raised and
propagated to the failure terminal (if wired).
- If authentication is specified in the security profile, the security manager calls the
configured security provider to authenticate the identity. A failure results in
a security exception being returned to the node. The security providers that are
supported by IBM® Integration Bus for authentication are a
LDAP, WS-Trust v1.3 compliant Security Token Service (such as TFIM V6.2), and
TFIM V6.1.
A security cache is provided for the authentication result, which
enables subsequent messages (with the same credentials) arriving at the
message flow to be completed with the cached result, provided that it has
not expired.
- If identity mapping is specified in the security profile, the security manager calls the
configured security provider to map the identity to an alternative identity. A
failure results in a security exception being returned to the node. Otherwise,
the mapped identity information is set in the Mapped Identity elements in the
Properties folder.
The security providers that are supported by IBM Integration Bus for identity mapping are a WS-Trust
V1.3 compliant Security Token Service (such as TFIM V6.2) and TFIM
V6.1.
A security cache is provided for the result of the identity
mapping.
- If authorization is specified in the security profile, the security manager calls the configured
security provider to authorize that the identity (either mapped or source) has
access to this message flow. A failure results in a security exception being
returned to the node.
The security providers that are supported by IBM Integration Bus for authorization are LDAP, a
WS-Trust V1.3 compliant Security Token Service (such as TFIM V6.2) and TFIM
V6.1.
A security cache is provided for the authorization
result.
- When all security processing is complete, or when a security exception
is raised by the message flow security manager, control returns to
the SecurityPEP node.
When a security exception is returned to the SecurityPEP node, the exception
is either propagated to the failure terminal if it is connected, or
returned to the preceding node as a recoverable exception. The SecurityPEP node propagates
to its Out terminal only if all the configured operations in the associated
security profile complete successfully.
- The message, including the populated Properties folder and its
source and mapped identity information, is propagated down the message
flow.
- When you are developing a message flow, you can use the identity fields in the Properties folder
for application processing (for example, identity-based routing or content building
based on identity). If the identity is to be propagated in an outbound message from
an output or request node that does not support propagation of the token, you can
use a compute node (including a Compute, JavaCompute, or Mapping node), to move the identity token into
the required transport header or message body location.
- When the message reaches an output node, a security profile associated
with the node can indicate whether an identity is to be taken from
the Properties folder and propagated when the message is sent. Only
specific transport nodes can propagate tokens that are the default
for the transport; any other token type must be handled by a compute
node, as described above.