Start of change

Access Control Lists

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:

This diagram shows an example hierarchy. The root is CMP, which has three children: RootTopic, Subscriptions, and PubSubTopology. PubSubTopology has two children: Broker1 and Broker2. Each broker has two children: Eg1A and Eg1B.

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).

The following command creates the ACL entry for UserB:
mqsicreateaclentry testcm -u UserB -a -x D -b Broker1 -e Eg1A
The mqsilistaclentry command then displays the following information:
BIP1778I: userb -USER  -  D  -  Broker1/Eg1A      -  ExecutionGroup

Example 3

UserC has an ACL entry that gives her View authority for the Configuration Manager Proxy (CMP), and an ACL entry that gives her Full authority for Broker1.This gives her the following authorities:

CMP View
RootTopic View
Subs View
Topology View
Broker1 Full
Eg1A Full
Eg1B Full
Broker2 View
Eg2A View
Eg2B View

The following commands create the ACL entries for UserC:
mqsicreateaclentry testcm -u UserC -a -x V -p
mqsicreateaclentry testcm -u UserC -a -x F -b Broker1
The mqsilistaclentry command then displays the following information:
BIP1778I: userc                -  USER  -  V  -  ConfigManagerProxy  -  ConfigManagerProxy
BIP1778I: userc                -  USER  -  F  -  Broker1              -  Broker

Example 4

UserD has an ACL entry that gives him Full authority for the CMP and an ACL entry that gives him View authority for Broker1. By giving UserD View authority to access Broker1, UserD does not inherit Full authority. This use of View ACL 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 authority, so that they can perform the operations that they need, then restore the View entry. UserD has the following authorities:

CMP Full
RootTopic Full
Subs Full
Topology Full
Broker1 View
Eg1A View
Eg1B View
Broker2 Full
Eg2A Full
Eg2B Full

The following commands create the ACL entries for UserD:
mqsicreateaclentry testcm -u UserD -a -x F -p
mqsicreateaclentry testcm -u UserD -a -x V -b Broker1
The mqsilistaclentry command then displays the following information:
BIP1778I: userd                -  USER  -  F  -  ConfigManagerProxy  -  ConfigManagerProxy
BIP1778I: userd                -  USER  -  V  -  Broker1              -  Broker
The 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.

Related concepts
Authorization to access runtime resources
Enabling the Configuration Manager on z/OS to obtain user ID information
Topic-based security
Related tasks
Setting up broker domain security
Enabling topic-based security
Canceling a deployment that is in progress
Adding a new topic
Related reference
mqsicreateaclentry command
mqsideleteaclentry command
mqsilistaclentry command
ACL permissions
End of change