|Skip Navigation Links|
|Exit Print View|
|Oracle GlassFish Server Message Queue 4.5 Administration Guide|
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 IMQ_VARHOME/instances/instanceName/etc.
The file is formatted as a Java properties file. It starts with a version property defining the version of the file:version=JMQFileAccessControlModel/100
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:resourceType.resourceVariant.operation.access.principalType=principals
Table 9-5 describes the various elements.
Table 9-5 Authorization Rule Elements
Example 9-3 Example 1
Description: allows all users to consume messages from the queue destination q1.
Example 9-4 Example 2
Description: allows user Snoopy to consume messages from all queue destinations.
Example 9-5 Example 3
Description: prevents Snoopy from producing messages to the topic destination t1
Note - 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 athttp://java.sun.com/j2se/1.4/docs/guide/intl/faq.html
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 rulesqueue.q1.produce.allow.user=* queue.q1.produce.deny.user=Snoopy
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 rulesqueue.q1.consume.allow.group=user queue.q1.consume.deny.user=Snoopy
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 rulestopic.t1.produce.deny.group=* topic.t1.produce.allow.user=*
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 rulestopic.*.consume.allow.user=Snoopy topic.t1.consume.deny.user=Snoopy
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 rulesqueue.q1.browse.deny.user=Snoopy queue.q1.browse.allow.user=Snoopy
prevent Snoopy from browsing queue q1. The rulestopic.t1.consume.deny.group=user topic.t1.consume.allow.group=user
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 rulesqueue.q1.browse.allow.user=Snoopy,Linus queue.q1.browse.allow.user=Snoopy
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 rulesconnection.NORMAL.allow.user=* connection.ADMIN.allow.group=admin
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 ruleconnection.NORMAL.deny.user=Snoopy
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 ruletopic.Admissions.consume.deny.group=user
denies all members of the user group the ability to subscribe to the topic Admissions.
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).
The final section of the access control file controls the ability of users and groups to auto-create destinations, and to access any auto-created destinations. 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 auto-created queues or all auto-created topics, rather than any specific destination.
The default access control file contains the rulesqueue.create.allow.user=* topic.create.allow.user=*
authorizing all users to have physical destinations auto-created for them by the broker, and to have access to any auto-created destinations. You can edit the file to restrict such authorization for specific users. For example, the ruletopic.create.deny.user=Snoopy
denies user Snoopy the ability to auto-create topic destinations or to access any auto-created topic destinations.
Note - 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.