JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Administration Guide
search filter icon
search icon

Document Information


Part I Introduction to Message Queue Administration

1.  Administrative Tasks and Tools

2.  Quick-Start Tutorial

Part II Administrative Tasks

3.  Starting Brokers and Clients

4.  Configuring a Broker

5.  Managing a Broker

6.  Configuring and Managing Connection Services

7.  Managing Message Delivery

8.  Configuring Persistence Services

9.  Configuring and Managing Security Services

Introduction to Security Services




User Authentication

Using a Flat-File User Repository

User Groups and Status

Using the User Manager Utility

Using an LDAP User Repository

To Set Up an Administrative User

Using JAAS-Based Authentication

Elements of JAAS

JAAS and Message Queue

Setting up JAAS-Compliant Authentication

User Authorization

Access Control File Syntax

Application of Authorization Rules

Authorization Rules for Connection Services

Authorization Rules for Physical Destinations

Authorization Rules for Auto--Created Physical Destinations

Message Encryption

Using Self-Signed Certificates

Setting Up an SSL-Based Connection Service Using Self-Signed Certificates

Configuring and Running an SSL-Based Client Using Self-Signed Certificates

Using Signed Certificates

Obtaining and Installing a Signed Certificate

Configuring the Client to Require Signed Certificates

Password Files

Security Concerns

Password File Contents

Connecting Through a Firewall

To Enable Broker Connections Through a Firewall

Audit Logging with the Solaris BSM Audit Log

10.  Configuring and Managing Broker Clusters

11.  Managing Administered Objects

12.  Configuring and Managing Bridge Services

13.  Monitoring Broker Operations

14.  Analyzing and Tuning a Message Service

15.  Troubleshooting

Part III Reference

16.  Command Line Reference

17.  Broker Properties Reference

18.  Physical Destination Property Reference

19.  Administered Object Attribute Reference

20.  JMS Resource Adapter Property Reference

21.  Metrics Information Reference

22.  JES Monitoring Framework Reference

Part IV Appendixes

A.  Distribution-Specific Locations of Message Queue Data

B.  Stability of Message Queue Interfaces

C.  HTTP/HTTPS Support

D.  JMX Support

E.  Frequently Used Command Utility Commands


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


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:


Table 9-5 describes the various elements.

Table 9-5 Authorization Rule Elements

Type of resource to which the rule applies:
  • connection: Connections

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

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

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


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.

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

denies all members of the user group the ability to subscribe to the topic Admissions.

Authorization Rules for Auto—Created Physical Destinations

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 rules

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


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.