WAS v8.5 > WebSphere applications > Service integration > Service integration securityDestination security
When messaging security is enabled, the authorization policy for resources on the service integration bus is enforced, and client applications must have authority to access bus destinations.
Destination authorization
Access to a destination is role-based. By assigning a group of users to a specific role for a specific bus destination, you authorize the group to undertake a specific operation on that bus destination. The roles for a destination depend on the type of destination:
You define destination role assignments on the bus that owns the destination. If a message is routed between two or more destinations, the members of a group require authority to access each of the destinations.
- Sender
- This role applies to alias, foreignDestination, port, queue, and topicSpace destinations.
- Receiver
- This role type applies to alias, port, queue, and topicSpace destinations.
- Browser
- This role type applies to alias, port, and queue destinations.
- Creator
- This role applies to temporary destinations only.
Temporary destination authorization
A temporary destination prefix, which is specified when a temporary destination is created, is used at runtime by the messaging engine to determine access authority for the temporary destination. When a temporary destination is created, the identity of its creator is assigned to the creator role for the temporary destination prefix. By default, all authenticated users can create temporary destinations. To grant the members of a group access to a temporary destination, you must assign the group to the sender role for the corresponding temporary destination prefix.
Multiple destinations authorization
When a message arrives at a destination, it might be routed onwards to one or more destinations before it is received by an application. This might happen, for example, if there is a mediation on the first destination. When the message arrives at the first destination, the messaging engine checks the identity of the sending application has authority in the sender role to send messages to the destination, and adds the identity of the sender to the message. If the message is routed on to another destination, the messaging engine checks the sender identity in the message has authority in the sender role for the destination to which it is being routed. The messaging engine continues to check the authority of the sending application along the forward routing path of the message until it arrives at a mediated destination. The mediation might (but does not always) replace the sender identity in the message with the mediation identity. If this happens, the messaging engine uses the mediation identity to check the authority of the sender to send to the next destination in the forward routing path, not the identity of the original sender.
Inheritance of security authorization
A destination can inherit role assignments from the default resource. Only role types that are permitted for a particular destination type can be inherited. For example, a queue destination can inherit the browser role from the default resource. Inherited role assignments are added to any existing role assignments for a destination. For example, a queue destination that has members of a group called Group 1 in the sender role, can inherit Group 2 in the sender role for the default resource.
Related concepts:
Bus destinations
Role-based authorization
Temporary bus destinations
Transactionality in mediations
Foreign destinations and alias destinations
Related
Administer destination roles
Secure service integration
Configure a destination forward routing path
Configure a destination reverse routing path
Reference:
Access role assignments for bus security resources
Define destination defaults inheritance using wsadmin
Related information:
Destinations access roles [Collection]