The messaging engine on a service integration bus uses role-based authorizations to ensure that local buses can exchange messages securely with foreign service integration buses, and with WebSphere® MQ.
Service integration authority is role-based. By assigning a group of user identities in the user repository to one or more access roles for a destination on a local bus, you can control who has authority to access, and undertake operations, on that bus destination. The messaging engine uses the role assignments at runtime to determine which operations group members can undertake on the destination. If a client application needs to exchange messages with another bus, you need to assign the identity of the client application to the sender and receiver roles for the remote (foreign) bus. When the client application sends a message from the local bus destination to the foreign bus destination, the messaging engine performs a two-stage check on the authority of the identity of the client application:
Messages are sent to a foreign bus destination by using either a foreign bus destination proxy definition, or a foreign bus definition. The definition contains the authority that determines whether the sender is authorized to send messages to the foreign bus. Foreign destination definitions enable you to grant authority on a destination by destination basis. If a foreign destination definition does not exist for a specific destination, the messaging engine uses the default foreign bus definition.
It is important to understand that it is the role assignments for the foreign bus, or foreign bus destination, that control whether a client application can send messages to the foreign bus. When the foreign bus receives a message, the messaging engine on the foreign bus uses the foreign bus role assignments to check whether the message can proceed to the foreign bus destination.
For the second stage authorization check, the messaging engine uses the identity that is stored in the message. This is initially set to the identity of the sending client application, but it might be superseded on the foreign bus destination by values specified by the Inbound user ID or Outbound user ID properties. In this case, the messaging engine uses the Inbound or Outbound user ID to undertake its authorization checks on the foreign bus, not the identity of the original sending client application.
The checks on Inbound and Outbound user IDs also apply when messages are routed through multiple buses, and when messages are sent to a WebSphere MQ network.
If secure buses are linked, the link between them should be secure. To protect data transmitted along the virtual link between buses by using SSL, you must define the required transport chains and then reference the transport chain name.