IBM® Integration Bus provides support for identity mapping (also known as identity federation) and token issuance and exchange. Identity mapping is the process of mapping an identity in one realm to another identity in a different realm. For example, you might map User001 from the eSellers realm to eSellerUser01 in the eShipping realm. Token issuance and exchange involves the mapping of a token of one type to a token of a different type. For example, an incoming Username and Password token from a client over MQ might be mapped into an equivalent SAML assertion, to be propagated to a Web Services call. Alternatively, you might exchange a SAML 1.1 assertion from a client application for an equivalent SAML 2.0 assertion for an updated backend server.
Mapping using a WS-Trust provider
The IBM Integration Bus security manager supports mapping operations through WS-Trust V1.3 compliant security token servers (STS), such as IBM Tivoli® Federated Identity Manager (TFIM) V6.2. Mapping is performed for SecurityPEP nodes and input nodes that have an associated security profile that includes a mapping operation configured with a WS-Trust V1.3 STS.
WS-Trust V1.3 (TFIM V6.2) can also be selected for authentication and authorization in the profile. However, if more than one security operation is associated with the security profile, only one WS-Trust request is issued to the STS. As a result, the STS must be configured to perform all the required operations. For example, if a TFIM V 6.2 server is specified, the TFIM module chain that is invoked must include the appropriate validate, authorize, and issue modules. If you require each operation to be performed through a separate WS-Trust call, you must use a series of SecurityPEP nodes, each associated with a different security profile that is configured for only one security operation (authentication, authorization, or mapping).
If the security profile specifies only mapping with WS-Trust v1.3 STS, the request is sent with a request type of Issue, whereas a mixed set of security operations sends a request type of Validate. When mapping is included, the STS must return a token in its response, even if it is the original token; otherwise, an error occurs.
To provide compatibility with previous versions of IBM Integration Bus, support is also provided for TFIM V6.1.
In the broker, identity mapping is performed at the input node or SecurityPEP node, after authentication but before authorization. The source identity is passed to an identity mapper for processing. If both mapping and authorization are configured, the authorization operation uses the mapped output token rather than the source token, which means that the authorization is performed on the federated identity.
Mapping is not performed in output nodes, even if the node has been configured with a security profile.
IBM Integration Bus supports mapping between any type of security token that is supported by the configured security provider. For more information about the support provided, see Identity.
When mapping from an X.509 certificate, TFIM can validate the certificate but cannot verify the identity of the original sender. However, if it is required, this verification integrity check can be performed by the SOAPInput node. For more information, see WS-Security mechanisms.
For more information about using TFIM V6.2 for mapping, see Authentication, mapping, and authorization with TFIM V6.2 and TAM.
For information about using TFIM V6.1, see Authentication, mapping, and authorization with TFIM V6.1 and TAM.
User-defined mapping
When you develop a message flow, you can implement a custom token mapping to be used for identity propagation. For example, you can implement a custom token mapping using a compute node (which can be a Compute, JavaCompute, or PHPCompute node) following the input node. In the compute node, you can read the source identity values from the Properties folder, process them, then write the new identity values to the mapped identity fields. If there is no identity provided in the message, you can still use a compute node to insert some identity credentials into the mapped identity fields. The mapped identity fields are then used in place of the source identity fields by subsequent nodes. Any security operations that are configured on the input node are performed using the source identity, before you can create a new identity in the mapped identity fields (by using the compute node). However, you can include a SecurityPEP node after your compute node has created a new mapped identity.
Last updated Friday, 21 July 2017