WAS v8.5 > WebSphere applications > Service integration > Service integration security

Access control for multiple buses

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, we 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:

First stage authorization check

When the client application sends a message from the local destination, the messaging engine checks the identity of the client application has authority in the sender role for the foreign bus destination.

Second stage authorization check

When the foreign bus destination receives the message, the messaging engine checks the message identity (which is initially set to the identity of the sending client application) has authority in the sender role for the foreign bus destination.

Messages are sent to a foreign bus destination 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 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.

If users or groups have the bus connector role for a foreign bus, you must take special care when assigning access roles. In particular, check for the following to ensure message delivery between an MQ Link and foreign buses:

If message delivery is interrupted, it is difficult to diagnose and resolve the problem.

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.

You specify Inbound and Outbound user IDs when we create a foreign bus connection or maintain the routing properties for the link to a foreign bus.

If secure buses are linked, the link between them should be secure. To protect data transmitted along the virtual link between buses using SSL, you must define the required transport chains and then reference the transport chain name.


Related


Secure service integration
Modify a routing definition
Configure foreign bus connections


Reference:

createSIBus command


+

Search Tips   |   Advanced Search