Sun Java System Message Queue 4.3 Administration Guide

User Authorization

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:

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.

Access Control File Syntax

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

   …/instances/brokerInstanceName/etc/accesscontrol.properties

(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:

   version=JMQFileAccessControlModel/100

This is followed by three sections specifying the access control for three categories of operations:

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

Element 

Description 

resourceType

Type of resource to which the rule applies:  

    connection: Connections


    queue: Queue destinations


    topic: Topic destinations


resourceVariant

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

Operation to which the rule applies 

This syntax element is not used for resourceType=connection.

access

Level of access authorized:  

    allow: Authorize user to perform operation


    deny: Prohibit user from performing operation


principalType

Type of principal (user or group) to which the rule applies:  

    user: Individual user


    group: User group


principals

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.


Example 9–3 Example 1

Rule: queue.q1.consume.allow.user=*

Description: allows all users to consume messages from the queue destination q1.



Example 9–4 Example 2

Rule: queue.*.consume.allow.user=Snoopy

Description: allows user Snoopy to consume messages from all queue destinations.



Example 9–5 Example 3

Rule: topic.t1.produce.deny.user=Snoopy

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 at

   http://java.sun.com/j2se/1.4/docs/guide/intl/faq.html

for more information.


Application of Authorization Rules

Authorization rules in the access control file are applied according to the following principles:

Authorization Rules for Connection Services

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

   connection.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 rule

   connection.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.

Authorization Rules for Physical Destinations

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:

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

   topic.Admissions.consume.deny.group=user

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

   queue.create.allow.user=*
   topic.create.allow.user=*

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

   topic.create.deny.user=Snoopy

denies user Snoopy the ability to auto-create topic destinations.


Note –

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.