Access control list (ACL) entries allow or deny a user
access to specific runtime resources. Runtime resources are WebSphere® Message
Broker objects
that exist at run time in the broker domain.
Each runtime object has an ACL that determines which users and
groups can access the object. Using ACL entries, you can control users' access
to specific objects in the broker domain, and permit a user or group to view,
modify, or deploy the object. You can manipulate the ACL entries by using
the workbench, the Java Configuration
Manager Proxy API,
or the mqsicreateaclentry, mqsideleteaclentry,
and mqsilistaclentry commands.
For example, user USER1 might be given access to modify BROKERA,
but have no access rights to BROKERB. In a further example, the same user
might have access to deploy to execution group EXEGRP1, but not to EXEGRP2,
even though they are both members of BROKERA.
The Configuration
Manager checks the ACL table
and, if your user ID is included in the ACL entry for the named object, you
are authorized to perform the operation.
There are four different access levels that can be granted for a user or group: Full control, 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 for a summary of the actions that the user or group can perform.
An ACL entry contains the user name and can specify a host name or domain name. For example, it is possible for a user to gain 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. Although ACL entries permit or deny access to an object based on the user ID, they do not secure the object because an ACL entry cannot verify the user's identity.
To reduce the number of ACL entries that a broker administrator must create, the ACL permissions operate 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, permission is granted to that object and to all objects beneath it in the hierarchy, unless it is overridden by another ACL entry. The following diagram shows an example hierarchy of access control list entries:
For examples showing how this hierarchy works in practice, see Configuring security for domain components.
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 previously, 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.
On z/OS®, you must define an OMVS segment for user IDs and groups, so that a Configuration Manager can obtain user ID and group information from the External Security Manager (ESM) database.
In previous versions of WebSphere Message Broker, access to runtime objects was controlled by defining a set of groups and assigning users to those groups. ACL entries enable you to control access with more granularity than groups. ACL entries also enable a single Configuration Manager to manage development, test, and production systems separately by configuring users' access to each broker. Using groups, you would have to place the development, test, and production systems in separate broker domains, each controlled by a separate Configuration Manager.
When you use single user ACLs, you must define the users on the workstation that is accessing the objects (that is, the machine on which the Toolkit is running), but you do not need to define them on the workstation that is running the Configuration Manager. However, when you are using Group ACLs, you must define the users on both workstations and then define the groups on the workstation that is running the Configuration Manager, before adding the users to the groups. This is necessary because no group information is passed between the workstations.