WebSphere Event Broker uses Access Control Lists (ACLs) to govern which users and groups can manipulate objects within the Configuration Manager and Message Brokers Toolkit. There are four different access levels that can be granted for a user or group: Full, View, Deploy and Edit. Not all access levels are valid for all object types; the table below describes which permissions can be applied to each object type and summarizes the actions that the user or group can perform.
In order to reduce the number of access control entries that a broker administrator must create, the ACL permissions behave in a hierarchical manner. The root of the tree is the ConfigManangerProxy object, which has three children: RootTopic, Subscriptions and PubSubTopology. The PubSubTopology object has zero or more brokers as children, and each broker can have zero or more execution groups as children. When an ACL entry is added to a given object, that permission is granted to that object and all objects beneath it in the hierarchy unless it is overridden by another ACL entry. The following diagram shows an example hierarchy:
The following scenarios show how this hierarchical behavior works in practice.
Scenario 1
UserA has no access control entries. Therefore, UserA cannot manipulate any objects in the hierarchy, or see any of the objects defined in the hierarchy.
Scenario 2
CMP None
RootTopic None
Subs None
Topology View
Broker1 View
Eg1A Deploy
Eg1B None
Broker2 None
Eg2A None
Eg2B None
Note that because an access control entry has been given to the execution group, it is given an implied View permission to the parent broker and the topology, otherwise it would not be visible in the tooling. As there are no actual ACL entries for this user for the broker or topology, however, there is no inherited access to the other broker or execution groups. In practice, this means that UserB can see that there is another execution group defined on that broker, but cannot see any details (including the name).
Similarly, UserB can see that another broker exists within the topology, but cannot see any details. UserB has no access to the RootTopic or to the subscriptions table.
Scenario 3
CMP View
RootTopic View
Subs View
Topology View
Broker1 Full
Eg1A Full
Eg1B Full
Broker2 View
Eg2A View
Eg2B View
Scenario 4
CMP Full
RootTopic Full
Subs Full
Topology Full
Broker1 View
Eg1A View
Eg1B View
Broker2 Full
Eg2A Full
Eg2B Full
Note that in this example, without the View entry for Broker1, the user would have full control. This use of View entries is useful because it allows users who usually have full control over a given object to reduce their access temporarily in order to prevent accidental deletion or deployment. If the user needs full control of the object, removing the View entry restores full control, so that they can perform the operations that they need, then restore the View entry.
In order to change the access control entries for an object, a user must have full control over that object or any parent in the hierarchy. This means that the permission to change the ACLs themselves works the same as described above, with the exception that access to the ACLs cannot be removed by granting a lower permission further down the tree; this is necessary because otherwise a user would be able to give themselves a View entry and would not then be able to remove it.
ACL entries can be manipulated using the Java Configuration Manager Proxy API or using the mqsicreateaclentry, mqsideleteaclentry, and mqsilistaclentry commands.
Object | Permission | Rights |
---|---|---|
Topology | Full control |
|
View |
|
|
Broker | Full control |
|
Deploy |
|
|
View |
|
|
Execution group | Full control |
|
Deploy |
|
|
View |
|
|
Root topic | Full control |
|
Deploy |
|
|
Edit |
|
|
View |
|
|
Subscription | Full control |
|
View |
|