An access control file contains rules that specify which users (or groups of users) are authorized to perform certain operations on a message broker. These operations include the following:
Creating a connection
Creating a message producer for a physical destination
Creating a message consumer for a physical destination
Browsing a queue destination
Auto-creating a physical destination
If access control is enabled (that is, if the broker’s imq.accesscontrol.enabled configuration property is set to true, the broker will consult its access control file whenever a client attempts one of these operations, to verify whether the user generating the request (or a group to which the user belongs) is authorized to perform the operation. By editing this file, you can restrict access to these operations to particular users and groups. Changes take effect immediately; there is no need to restart the broker after editing the file.
Each broker has it own access control file, created automatically when the broker is started. The file is named accesscontrol.properties and is located at a path of the form
(See Appendix A, Platform-Specific Locations of Message Queue Data for the exact location, depending on your platform.)
The file is formatted as a Java properties file. It starts with a version property defining the version of the file:
This is followed by three sections specifying the access control for three categories of operations:
Creating message producers or consumers, or browsing a queue destination
Auto-creating physical destinations
Each of these sections consists of a sequence of authorization rules specifying which users or groups are authorized to perform which specific operations. These rules have the following syntax:
Table 9–5 describes the various elements.Table 9–5 Authorization Rule Elements
Type of resource to which the rule applies:
queue: Queue destinations
topic: Topic destinations
Specific resource (connection service type or destination) to which the rule applies
An asterisk (*) may be used as a wild-card character to denote all resources of a given type: for example, a rule beginning with queue.* applies to all queue destinations.
Operation to which the rule applies
This syntax element is not used for resourceType=connection.
Level of access authorized:
allow: Authorize user to perform operation
deny: Prohibit user from performing operation
Type of principal (user or group) to which the rule applies:
user: Individual user
group: User group
List of principals (users or groups) to whom the rule applies, separated by commas
An asterisk (*) may be used as a wild-card character to denote all users or all groups: for example, a rule ending with user=* applies to all users.
Description: allows all users to consume messages from the queue destination q1.
Description: allows user Snoopy to consume messages from all queue destinations.
Description: prevents Snoopy from producing messages to the topic destination t1
You can use Unicode escape (\\uXXXX) notation to specify non-ASCII user, group, or destination names. If you have edited and saved the access control file with these names in a non-ASCII encoding, you can use the Java native2ascii tool to convert the file to ASCII. See the Java Internationalization FAQ at
for more information.
Authorization rules in the access control file are applied according to the following principles:
Any operation not explicitly authorized through an authorization rule is implicitly prohibited. For example, if the access control file contains no authorization rules, all users are denied access to all operations.
Authorization rules for specific users override those applying generically to all users. For example, the rules
authorize all users except Snoopy to send messages to queue destination q1.
Authorization rules for a specific user override those for any group to which the user belongs. For example, if user Snoopy is a member of group user, the rules
authorize all members of user except Snoopy to receive messages from queue destination q1.
Authorization rules applying generically to all users override those applying to all groups. For example, the rules
authorize all users to publish messages to topic destination t1, overriding the rule denying such access to all groups.
Authorization rules for specific resources override those applying generically to all resources of a given type. For example, the rules
authorize Snoopy to subscribe to all topic destinations except t1.
Authorization rules authorizing and denying access to the same resource and operation for the same user or group cancel each other out, resulting in authorization being denied. For example, the rules
prevent Snoopy from browsing queue q1. The rules
prevent all members of group user from subscribing to topic t1.
When multiple authorization rules are specified for the same resource, operation, and principal type, only the last rule applies. The rules
authorize user Snoopy, but not Linus, to browse queue destination q1.
Authorization rules with the resource type connection control access to the broker’s connection services. The rule’s resourceVariant element specifies the service type of the connection services to which the rule applies, as shown in Table 6–1; the only possible values are NORMAL or ADMIN. There is no operation element.
The default access control file contains the rules
giving all users access to NORMAL connection services (jms, ssljms, httpjms, and httpsjms) and those in the admin group access to ADMIN connection services (admin and ssladmin). You can then add additional authorization rules to restrict the connection access privileges of specific users: for example, the rule
denies user Snoopy access privileges for connection services of type NORMAL.
If you are using a file-based user repository, the admin user group is created by the User Manager utility. If access control is disabled (imq.accesscontrol.enabled = false), all users in the admin group automatically have connection privileges for ADMIN connection services. If access control is enabled, access to these services is controlled by the authorization rules in the access control file.
If you are using an LDAP user repository, you must define your own user groups in the LDAP directory, using the tools provided by your LDAP vendor. You can either define a group named admin, which will then be governed by the default authorization rule shown above, or edit the access control file to refer to one or more other groups that you have defined in the LDAP directory. You must also explicitly enable access control by setting the broker’s imq.accesscontrol.enabled property to true.
Access to specific physical destinations on the broker is controlled by authorization rules with a resource type of queue or topic, as the case may be. These rules regulate access to the following operations:
Sending messages to a queue: produce operation
Receiving messages from a queue: consume operation
Publishing messages to a topic: produce operation
Subscribing to and consuming messages from a topic: consume operation
Browsing a queue: browse operation
By default, all users and groups are authorized to perform all of these operations on any physical destination. You can change this by editing the default authorization rules in the access control properties file or overriding them with more specific rules of your own. For example, the rule
denies all members of the user group the ability to subscribe to the topic Admissions.
The final section of the access control file, includes authorization rules that specify for which users and groups the broker will auto-create a physical destination.
When a client creates a message producer or consumer for a physical destination that does not already exist, the broker will auto-create the destination (provided that the broker’s imq.autocreate.queue or imq.autocreate.topic property is set to true).
A separate section of the access control file controls the ability of users and groups to perform such auto-creation. This is governed by authorization rules with a resourceType of queue or topic and an operation element of create. the resourceVariant element is omitted, since these rules apply to all queues or all topics, rather than any specific destination.
The default access control file contains the rules
authorizing all users to have physical destinations auto-created for them by the broker. You can edit the file to restrict such authorization for specific users. For example, the rule
denies user Snoopy the ability to auto-create topic destinations.
Note that the effect of such auto-creation rules must be congruent with that of other physical destination access rules. For example, if you change the destination authorization rule to prohibit any user from sending a message to a queue, but enable the auto-creation of queue destinations, the broker will create the physical destination if it does not exist, but will not deliver a message to it.