Setting Permissions


Permissions are stored in the access control list and determine the actions a user can perform on a destination. A user’s permissions are the union of the permissions granted explicitly to that user along with any permissions the user receives by belonging to a group.

When granting permissions, you specify the user or group to whom you wish to grant the permission, the name of the destination, and the permission(s) to grant. Granting permissions is an action that is independent from both the authorization server parameter, and the secure property of the relevant destinations. The currently granted permissions are stored in the access control file, however, the server enforces them only if the authorization is enabled, and only for secure destinations.

When setting permissions for users and groups defined externally, user and group names are case-sensitive. Make sure you use the correct case for the name when setting the permissions.

Permissions can only be granted by users that have the appropriate administrator permissions. See Administrator Permissions for more information.

You can specify either explicit destination names or wildcard destination names. See Inheritance of Permissions for more information on wildcard destination names and permissions.

Topics and queues each have associated permissions. Table 31 describes the permissions specific to queues. Table 32 describes the permissions specific to topics.

Table 31 Queue Permission 
Name
Description
receive
permission to create queue receivers
send
permission to create queue senders
browse
permission to create queue browsers

Table 32 Topic Permission (Sheet 1 of 2)
Name
Description
subscribe
permission to create non-durable subscribers on the topic
publish
permission to publish on the topic
durable
permission to create durable subscribers on the topic
use_durable
permission to use existing durable subscribers on the topic, but not to create nor configure them

You assign permissions either by specifying them in the acl.conf file, using the tibemsadmin tool, or by using the administration APIs.

Example of Setting Permissions

The user bob has the following permission recorded in the acl.conf file:

USER=bob TOPIC=foo PERM=subscribe,publish 

This set of permissions means that bob can subscribe to topic foo and publish messages to it, but bob cannot create durable subscribers to foo.

If bob is a member of group engineering and the group has the following entry in the acl file:

GROUP=engineering TOPIC=bar PERM=subscribe,publish 

then bob can publish and subscribe to topics foo and bar.

If both the user bob and the group engineering have entries in the acl.conf file, then bob has permissions that are a union of all permissions set for bob directly and the permissions of the group engineering.

Inheritance of Permissions

When you grant permissions to users for topics or queues with wildcard specifications, all created topics and queues that match the specification will have the same granted permissions as the permissions on the parent topic. If there are multiple parent topics, the user receives the union of all parent topic permissions for any child topic. You can add permissions to a user for topics or queues that match a wildcard specification, but you cannot remove permissions.

For example, you can grant user Bob the browse permission on queue foo.*. The user Bob receives the browse permission on the foo.bar queue, and you can also grant Bob the send permission on the foo.bar queue. However, you cannot take away the inherited browse permission from Bob on the foo.bar queue.

See Wildcards for more information about wildcards in destination names.


TIBCO Enterprise Message Service™ User’s Guide
Software Release 4.3, February 2006
Copyright © TIBCO Software Inc. All rights reserved
www.tibco.com