Access Control List (ACL) entries allow or deny a user to access an object. ACL entries do not, however, secure the object because the ACL entry cannot verify the user's identity. An ACL entry contains the user name and can specify a host name or domain name. It is possible, for example, for a user to get access to the objects by creating an account on a computer that has a host name that is the same as an authorized Windows domain name. Use ACL entries to control access to the objects in the broker domain but do not rely on ACL entries to secure your broker domains; use SSL or security exits to secure the channels between components in the broker domain.
WebSphere Event Broker uses Access Control List (ACL) entries to govern which users and groups can manipulate objects in the broker domain. 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; see ACL permissions for a list of the permissions that can be applied to each object type and a summary of 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 to all objects beneath it in the hierarchy, unless it is overridden by another ACL entry.
On z/OS, you must define an OMVS segment for user IDs and groups, in order for a Configuration Manager to obtain user ID and group information from the External Security Manager (ESM) database.
The following diagram shows an example hierarchy:
The following examples show how this hierarchical behavior works in practice.
Example 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.
Example 2
UserB has an ACL entry that gives him Deploy authority to the execution group Eg1A. This gives him implied View authority to PubSubTopology and Broker1. UserB must be able to view PubSubTopology and Broker1 (for example, in the Message Brokers Toolkit) to be able to deploy to Eg1A.
Because UserB does not have any ACL entries for PubSubTopology or Broker1, UserB does not inherit access to the other broker or execution groups in the hierarchy. In practice, this means that UserB can see that there is another execution group defined on the broker Broker1 but cannot see any details (including the execution group's name). Similarly, UserB can see that another broker exists within the topology, but cannot see any details. UserB has no access to RootTopic or to Subscriptions (the subscriptions table).
mqsicreateaclentry testcm -u UserB -a -x D -b Broker1 -e Eg1AThe mqsilistaclentry command then displays the following information:
BIP1778I: userb -USER - D - Broker1/Eg1A - ExecutionGroup
Example 3
CMP View
RootTopic View
Subs View
Topology View
Broker1 Full
Eg1A Full
Eg1B Full
Broker2 View
Eg2A View
Eg2B View
mqsicreateaclentry testcm -u UserC -a -x V -p mqsicreateaclentry testcm -u UserC -a -x F -b Broker1The mqsilistaclentry command then displays the following information:
BIP1778I: userc - USER - V - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userc - USER - F - Broker1 - Broker
Example 4
CMP Full
RootTopic Full
Subs Full
Topology Full
Broker1 View
Eg1A View
Eg1B View
Broker2 Full
Eg2A Full
Eg2B Full
mqsicreateaclentry testcm -u UserD -a -x F -p mqsicreateaclentry testcm -u UserD -a -x V -b Broker1The mqsilistaclentry command then displays the following information:
BIP1778I: userd - USER - F - ConfigManagerProxy - ConfigManagerProxy BIP1778I: userd - USER - V - Broker1 - BrokerThe following command can then delete the ACL entries for UserD:
mqsideleteaclentry testcm -u UserD -a -b Broker1
To change the access control entries for an object, a user must have Full authority for that object or any parent in the hierarchy. This means that the permission to change the ACLs themselves works in the same way 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.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ap01380_ |