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:
- 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.
- 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 broker'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 either the mqsicreateconfigurableservice command or an editor in the IBM® Integration Explorer. You then use the Broker Archive 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 Message
Broker for authentication are LDAP, WS-Trust v1.3 compliant security
token servers (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 Message Broker for identity mapping are WS-Trust V1.3 compliant security token servers (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 Message Broker for authorization are LDAP, WS-Trust V1.3 compliant security token servers (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, PHPCompute, 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.
Last updated Friday, 21 July 2017