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