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.