Start of change

Configuring security for domain components

Configure access control lists (ACLs) to control access to runtime resources.

When you have created the runtime resources (for example, the brokers and execution groups) and secured the transport connection, you need to configure access control lists (ACLs) to control which objects can be accessed by which user IDs. Default access, which you have until you have configured the ACLs, is Full control access for the Configuration Manager service ID only.

To configure your ACLs:

  1. Decide which objects you want to control, by referring to the hierarchy of ACLs that can be defined.
  2. Use the mqsicreateaclentry command to define permissions for each object that requires non-default access.
  3. Optional: If you are a publish/subscribe user, you can define other ACLs for application-level access to publish and subscribe on specified topics. These are also controlled using the mqsicreateaclentry command, but are not needed for administration.
When the ACLs have been configured, users of the workbench and commands are able to work with objects in the domain. The control that the users have over the objects (Full control, View, Deploy, or Edit) depends on the access that you have granted to them in the access control list entries.

The following diagram shows an example hierarchy of access control list entries:

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 hierarchy 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 it.

Example 2

UserB has an ACL entry that gives Deploy authority to the execution group Eg1A. This entry gives UserB 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 name of the execution group). 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 View authority for the Configuration Manager Proxy (CMP), and an ACL entry that gives Full authority for Broker1. These entries give UserC 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 Full control authority for the CMP, and an ACL entry that gives View authority for Broker1. The View authority to access Broker1 means that UserD does not inherit Full control authority for Broker1. 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, to prevent accidental deletion or deployment. If users need full control of the object, removing the View entry restores Full control authority, so that they can perform the operations that they need, and 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
Related concepts
Security overview
Security for runtime resources: Access control lists
Related tasks
Setting up broker domain security
Enabling topic-based security
Related reference
Security requirements for administrative tasks
mqsicreateaclentry command
mqsideleteaclentry command
mqsilistaclentry command
ACL permissions
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. All Rights Reserved.
Last updated : 2009-01-07 15:40:59

ap03987_

End of change