Message flow security overview

IBM® Integration Bus provides a security manager to control access to individual messages in a message flow, by using the identity of the message.

You can configure an integration node for processing end-to-end an identity that is carried in a message through a message flow by using a security profile. By creating a security profile, you can configure security for a message flow to control access based on the identity that is associated with the message and provides a security mechanism that is independent of both the transport type and message format.

Only a subset of the connectors available in IBM Integration Bus use security profiles to control and vary the identity that is used when the connector interacts with an external system. For other connectors, a fixed identity can be specified, which is used to authorize access to the external system. For those connectors, the integration node has its own repository of identities, which can be updated with the mqsisetdbparms and mqsireportdbparms command. For more information about which external systems use one of these identities to connect, see Advanced configuration.

If you do not enable message flow security, the default security facilities that are in IBM Integration Bus are based on the security facilities that are provided by the transport mechanism. In this case, the integration node processes all messages that are delivered to it, using the integration node service identity as a proxy identity for all message instances. Any identity that is present in the incoming message is ignored.

The security manager enables the integration node to:
  • Extract the identity from an inbound message
  • Authenticate the identity (by using an external security provider)
  • Map the identity to an alternative identity (by using an external security provider)
  • Check that either the alternative identity or the original identity is authorized to access the message flow (by using an external security provider)
  • Propagate either the alternative identity or the original identity with an outbound message.
The security functions that are associated with a message flow are controlled by using Security profiles, which are created by the integration node administrator and accessed by the security manager at runtime. The following external security providers (also known as Policy Decision Points or PDPs) are supported:
  • Tivoli® Federated Identity Manager (TFIM) V6.1 for authentication, mapping, and authorization
  • WS-Trust V1.3 compliant Security Token Service (including TFIM V6.2) for authentication, mapping, and authorization
  • Lightweight Directory Access Protocol (LDAP) for authentication and authorization
  • Windows Domain Controllers for authentication
  • Kerberos KDCs for authentication

You can invoke message flow security by configuring either a security enabled input node or a SecurityPEP node. You can use the SecurityPEP node to invoke the message flow security manager at any point in the message flow between an input node and an output (or request) node.

For an overview of the sequence of events that occur when the message flow security manager is invoked by using either a security enabled input node or a SecurityPEP node, see the following topics:
The input nodes that support message flow security are:
  • MQInput
  • HTTPInput
  • SCAInput
  • SCAAsyncResponse
  • SOAPInput

However, the support for treating security exceptions as normal exceptions is provided by only the MQInput, HTTPInput, SCAInput, and SCAAsyncResponse nodes; it is not available in the SOAPInput node.

The output nodes that support identity propagation are:
  • MQOutput
  • HTTPRequest
  • SCARequest
  • SCAAsyncRequest
  • SOAPRequest
  • SOAPAsyncRequest

If the message flow is a web service that is implemented by using the SOAP nodes, the identity can be taken from the WS-Security header tokens that are defined through appropriate Policy sets and bindings.

To improve performance, the integration node security manager uses a security cache. Entries are created in the security cache when a message flow with a security profile performs authentication, mapping, or authorization. The entries are valid for the length of time that is specified by the cacheTimeout property of the securitycache component after which the entries are marked as expired. When an entry is marked as expired, it must be reauthenticated, mapped, or reauthorized with the security provider before it can be reused, and its expiry time is reset. You can use the mqsireloadsecurity command to force the immediate expiry of some or all of the entries in the security cache.

For a SOAPRequest and SOAPAsyncRequest node, an appropriate policy set and bindings can be defined to specify how the token is placed in the WS-Security header (rather than the underlying transport headers). For more information, see Policy sets.

The following topics in this section provide more detailed information about message flow security: