> User Permissions
> User 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 user 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.

> User permissions can only be granted by an administrator with the appropriate permissions described in Administrator Permissions.
> You assign permissions either by specifying them in the acl.conf file, using the tibemsadmin tool, or by using the administration APIs. When setting user permissions, you can specify either explicit destination names or wildcard destination names. See Inheritance of User Permissions for more information on wildcard destination names and permissions.
> The permissions that can be granted to users to access queues are listed in Table 38; the permissions to access topics are listed in Table 39.

> Table 38 Queue Permission
> Name | Description
> receive | permission to create queue receivers
> send | permission to create queue senders
> browse | permission to create queue browsers

> Table 39 Topic Permission
> Name | Description
> subscribe | permission to create non-durable subscribers on the topic
> publish | permission to publish on the topic
> durable | permission to create, delete, or modify durable subscribers on the topic
> use_durable | permission to use an existing durable subscriber on the topic, but not to create, delete, or modify the durable subscriber

> Example of Setting User 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 User 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.
> Revoking User Permissions
> Administrators can revoke permissions for users to create consumers on a destination. Without permission, the user cannot create new consumers for a destination—however, existing consumers of the destination continue to receive messages.
> You can only revoke a permission that is granted directly. That is, you cannot revoke a permission from a user that the user receives from a group. Also, you cannot revoke a permission that is inherited from a parent topic. The revoke command in tibemsadmin can only remove items from specific entries in the acl.conf file. The revoke command cannot remove items that are inherited from other entries.
> You can revoke permissions in several ways:

> ● | Remove or edit entries in the acl.conf file.

> ● | Use the revoke commands in tibemsadmin; see page 127.

> ● | Use the administration APIs.

Copyright © TIBCO Software Inc. All Rights Reserved.