ACL permissions

WebSphere Message 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:

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

UserB has a Deploy entry for Eg1A. Therefore, UserB has the following permissions:

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

UserC has a View entry for the Configuration Manager Proxy (CMP), and a Full control entry for Broker1. Therefore, UserC has the following permissions:

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

Scenario 4

UserD has Full control entry for the CMP and a View entry for Broker1. Therefore, UserD has the following permissions:

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.

The following table explains the actions which can be performed by a user with a given permission:
Object Permission Rights
Topology Full control
  • Create and delete brokers.
  • Create and delete collectives.
  • Add and remove brokers from collectives.
  • Create and delete connections.
  • Deploy topology.
  • All topology View permission rights
View
  • View topology configuration and managed subcomponents.
Broker Full control
  • Create and delete execution groups.
  • Edit all broker properties.
  • All broker Deploy permission rights.
  • All execution groups Full control permission rights for contained execution groups.
  • All broker View permission rights.
Deploy
  • Deploy broker configuration.
  • All broker View permission rights.
View
  • View broker configuration and managed subcomponents.
  • Implicit view access to Topology.
Execution group Full control
  • Edit all execution group properties.
  • Start and stop execution groups.
  • All execution group Deploy permission rights.
  • All execution group View permission rights.
Deploy
  • Deploy execution group configuration.
  • Start and stop assigned message flows.
  • Start and stop trace.
  • All execution group View permission rights.
View
  • View execution group configuration and managed subcomponents.
  • Implicit View access to parent broker and topology.
Root topic Full control
  • Edit "Topic Access Control List".
  • All root topic Deploy permissions.
  • All root topic Edit permissions.
  • All root topic View permissions.
Deploy
  • Deploy entire topic configuration.
  • All root topic View permissions.
Edit
  • Create and delete child topics.
  • All root topic View permissions.
View
  • View all topics (including child topics), and any managed subcomponents.
Subscription Full control
  • Delete any subscription.
  • All subscription "View" permissions.
View
  • View or query all subscriptions and any managed subcomponents.
Related concepts
Security for runtime resources
Topic-based security
Related tasks
Setting up broker domain security
Enabling topic-based security
Adding a new topic
Related reference
mqsicreateaclentry command
mqsideleteaclentry command
mqsilistaclentry command
ACL updates