Message flow security overview

IBM® App Connect Enterprise 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 server 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 provide a security mechanism that is independent of both the transport type and message format.

Only a subset of the connectors available in IBM App Connect Enterprise 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 server has its own repository of identities, which can be updated by using the mqsivault and mqsicredentials commands.

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

The security functions that are associated with a message flow are controlled by using Security profiles, which are created by the App Connect Enterprise administrator and accessed by the security manager at runtime.

The security manager enables the integration server to:
  • Extract the identity from an inbound message
  • Authenticate the identity, by using either an external security provider (such as LDAP) or a locally stored identity in the integration server vault
  • 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 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

As an alternative to using an external security provider to authenticate an identity, you can use an identity stored locally in the integration server vault. For more information, see Authenticating incoming requests by using credentials stored in the vault.

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
  • SOAPInput
The support for treating security exceptions as normal exceptions is provided by only the MQInput and HTTPInput nodes; it is not available in the SOAPInput node.
The output nodes that support identity propagation are:
  • CICSRequest
  • HTTPRequest
  • HTTPAsyncRequest
  • IMSRequest
  • MQOutput
  • MQReply
  • RESTRequest
  • RESTAsyncRequest
  • SAPRequest
  • SiebelRequest
  • SOAPRequest
  • SOAPAsyncRequest
  • SOAPReply
  • SecurityPEP

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 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. For information about specifying a value for the cacheTimeout property, see Configuring the security cache. 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: