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.
Name
|
Description
|
---|---|
receive
|
permission to create queue receivers
|
send
|
permission to create queue senders
|
browse
|
permission to create queue browsers
|
You assign permissions either by specifying them in the acl.conf
file, using the tibemsadmin
tool, or by using the administration APIs.
The user bob
has the following permission recorded in the acl.conf
file:
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:
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
.
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 |