Security for runtime resources: Access control lists

Start of changeAccess control list (ACL) entries allow or deny a user access to specific runtime resources. Runtime resources are WebSphere® Event Broker objects that exist at run time in the broker domain.End of change

Start of changeEach 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. End of change

Start of changeFor 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.End of change

When you try to view or modify an object for which you require permission, the following information is passed to the Configuration Manager:

Start of changeThe 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.End of change

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:

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.

Start of changeFor examples showing how this hierarchy works in practice, see Configuring security for domain components.End of change

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.

ACL entries and groups

In previous versions of WebSphere Event 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.

If you migrate a Configuration Manager from a previous version of WebSphere Event Broker, ACL entries are automatically defined for the following groups:
  • mqbrkrs
  • mqbrops
  • mqbrdevt
  • mqbrasgn
  • mqbrtpic
Without these ACL entries, users that belong to these groups do not have authority to perform actions on the objects in the domain.

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.

Related concepts
Security overview
Enabling the Configuration Manager on z/OS to obtain user ID information
Topic-based security
Related tasks
Configuring security for domain components
Setting up broker domain security
Enabling topic-based security
Canceling a deployment that is in progress
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:58

ap01380_