Administrator Permissions


Administrators are a special class of users that can manage the TIBCO Enterprise Message Service server. Administrators create, modify, and delete users, destinations, routes, factories, and other items. In general, administrators must be granted permission to perform administration activities when using the administration tool or API. Administrators can be granted global permissions (for example, permission to create users or to view all queues), and administrators can be granted permissions to perform operations on specific destinations (for example, purging a queue, or viewing properties for a particular topic).

Administrator permissions control what administrators can view and change in the server only when using the administration tool or API. Administrator commands create entries in each of the configuration files (for example, tibemsd.conf, acl.conf, routes.conf, and so on).
You should control access to the configuration files so that only certain system administrators can view or modify the configuration files. If a user can view or modify the configuration files, setting permissions to control which destination that user can manage would not be enforced when the user manually edits the files.
Use the facilities provided by your Operating System to control access to the server’s configuration files.

Administrators cannot be defined in an external directory. Administrators must be created using the administration tool, the administration APIs, or in the configuration files.

Predefined Administrative User and Group

There is a special, predefined user named admin that can perform any administrative action. You cannot grant or revoke any permissions to admin. This user is created when the server is installed, and you must change the password for admin immediately after installation. For more information about changing the admin password, see When You First Start tibemsadmin.

There is also a special group named $admin for system administrator users. When a user becomes a member of this group, that user receives the same permissions as the admin user. You cannot grant or revoke administrator permissions from any user that is a member of the $admin group. You should only assign the overall system administrator(s) to the $admin group.

Granting and Revoking Administration Permissions

You grant and revoke administrator permissions to users using the grant and revoke commands in tibemsadmin. You can either grant global administrator permissions or permissions on specific destinations. See Global Administrator Permissions for a complete list of global administrator permissions. See Destination-Level Permissions for a description of administrator permissions for destinations.

Global and destination-level permissions are granted and revoked separately using different administrator commands. See Command Listing for the syntax of the grant and revoke commands.

If a user has both global and destination-level administrator permissions, the actions that user can perform are determined by combining all global and destination-level administrator permissions granted to the user. For example, if an administrator is granted the view-destination permission, that administrator can view information about all destinations, even if the view permission is not granted to the administrator for specific destinations.

The admin user or all users in the $admin group can grant or revoke any administrator permission to any user. All other users must be granted the change-admin-acl permission and the view-user and/or the view-group permissions before they can grant or revoke administrator permissions to other users.

If a user has the change-admin-acl permission, that user can only grant or revoke permissions that have been granted to the user. For example, if user BOB is not part of the $admin group and he has only been granted the change-admin-acl and view-user permissions, BOB cannot grant any administrator permissions except the view-user or change-admin-acl permissions to other users.

Users have all administrator permissions that are granted to any group to which they belong. You can create administrator groups, grant administrator permissions to those groups, and then add users to each administrator group. The users will be able to perform any administrative action that is allowed by the permissions granted to the group to which the user belongs.

Any destination-level permission granted to a user or group for a wildcard destination is inherited for all child destinations that match the parent destination.

If protection permissions are set up, administrators can only grant or revoke permissions to other users that have the same protection permission as the administrator. See Protection Permissions for more information about protection permissions.

Enforcement of Administrator Permissions

An administrator can only perform actions for which the administrator has been granted permission. Any action that an administrator performs may be limited by the set of permissions granted to that administrator.

For example, an administrator has been granted the view permission on the foo.* destination. This administrator has not been granted the global view-destination permission. The administrator is only able to view destinations that match the foo.* parent destination. If this administrator is granted the global view-acl permission, the administrator is only able to view the access control list for destinations that match the foo.* parent. Any access control lists for other destinations are not displayed when the administrator performs the showacl topic or showacl queue commands.

In some cases, enforcement of permissions causes the administrator to see little or no output for any view administrator commands. An administrator will receive an error when attempting to view a specific item for which the administrator does not have permission. For example, if the administrator above issues the showacl queue command, and there are no queues named foo.*, the command executes and returns no output. However, if the administrator issues the showacl queue bar.foo command, the administrator receives a “Not authorized to execute command” error because the administrator is not authorized to view any destination except those that match foo.*.

An administrator can always change his/her own password, even if the administrator is not granted the change-user permission.
An administrator can always view his/her own permissions by issuing the show acl <username> command, even if the administrator is not granted the view-acl permission.

Global Administrator Permissions

Certain permissions allow administrators to perform global actions, such as creating users or viewing all queues.

Table 33 describes the global administrator permissions.

Table 33 Global administrator permissions (Sheet 1 of 2)
Permission
Allows Administrator To...
all

Perform all administrative commands.

change-acl

Grant and revoke user-level permissions.

change-admin-acl

Grant and revoke administrative permissions.

change-bridge

Create and delete destination bridges.

change-connection

Delete connections.

create-destination
Create any destination.
modify-destination
Modify any destination.
delete-destination
Delete any destination.
change-durable

Delete durable subscribers.

change-factory

Create, delete, and modify factories.

change-group

Create, delete, and modify groups.

change-message
Delete messages stored in the server.
change-route

Create, delete, and modify routes

change-server
Modify server parameters.
change-user

Create, delete, and modify users.

purge-destination
Purge destinations.
purge-durable

Purge durable subscribers.

shutdown

Shutdown the server.

view-acl

View user-level permissions.

view-admin-acl

View administrative permissions.

view-all

View any item that can be administered (for example, users, groups, topics, and so on).

view-connection

View connections, producers and consumers.

view-bridge

View destination bridges.

view-destination

View destination properties and information.

view-durable

View durable subscribers.

To view a durable subscriber, you must also have view-destination permission (because information about a durable subscriber includes information about the destination to which it subscribes.)

view-factory

View factories.

view-group

View all groups.

Granting this permission implicitly grants view-user as well.

view-message
View messages stored in the server.
view-route

View routes.

view-server
View server configuration and information.
view-user

View any user.

Any type of modification to an item requires that the user can view that item. Therefore, granting any create, modify, delete, change, or purge permission implicitly grants the permission to view the associated item.
Granting the view permissions is useful when you want specific users to only be able to view items. It is not necessary to grant the view permission if a user already has a permission that allows the user to modify the item.

Global permissions are stored in the acl.conf file, along with all other permissions. Global permissions in this file have the following syntax:

ADMIN USER=<username> PERM=<permission> 

or

ADMIN GROUP=<groupname> PERM=<permission> 

For example, if a user named BOB is granted the view-user global administration permission and the group sys-admins is granted the change-acl permission, the following entries are added to the acl.conf file:

ADMIN USER=BOB PERM=view-user 
ADMIN GROUP=sys-admins PERM=change-acl 

Destination-Level Permissions

Administrators can be granted permissions on each destination. Destination-level permissions control the administration functions a user can perform on a specific destination. Global permissions granted to a user override any destination-level permissions.

The typical use of destination-level administration permissions is to specify permissions on wildcard destinations for different groups of users. This allows you to specify particular destinations over which a group of users has administrative control. For example, you may allow one group to control all ACCOUNTING.* topics, and another group to control all PAYROLL.* queues.

Table 34 describes the destination-level administration permissions.

Table 34 Destination-level administration permissions 
Permission
Allows Administrator To...
view
View information for this destination.
create
Create the specified destination. This permission is useful when used with wildcard destination names. This allows the user to create any destination that matches the specified parent.
delete
Delete this destination.
modify
Change the properties for this destination.
purge
Either purge this queue, if the destination is a queue, or purge the durable subscribers, if the destination is a topic with durable subscriptions.

Any type of modification to an item requires that the user can view that item. Therefore, granting create, modify, delete, change, or purge implicitly grants the permission to view the associated item.
Granting the view permissions is useful when you want specific users to only be able to view items. It is not necessary to grant the view permission if a user already has a permission that allows the user to modify the item.

Administration permissions for a destination are stored alongside all other permissions for the destination in the acl.conf file. For example, if user BOB has publish and subscribe permissions on topic foo, and then BOB is granted view permission, the acl listing would look like the following:

TOPIC=foo USER=BOB PERM=publish,subscribe,view 

Both user and administrator permissions for a destination are stored in the same entry in the acl.conf file. This is for convenience rather than for clarity. User permissions specify the actions a client application can perform on a destination (publish, subscribe, send, receive, and so on). Administrator permissions specify what administrative commands the user can perform on the destination when using the administration tool or API.

Protection Permissions

Protection permissions allow you to group users into administrative domains so that administrators can only perform actions within their domain. An administrator can only perform administrative operations on a user that has the same protection permission as the user. There are four protection permissions (protect1, protect2, protect3, and protect4) that allow you to create four groups of administrators. Protection permissions do not apply to the admin user or users in the $admin group — these users can perform any action on any user regardless of protection permissions.

To use protection permissions, grant one of the protection permissions to a set of users (either individually, or to a defined group(s)). Then, grant the same protection permission to the administrator that can perform actions on those users.

For example, there are four departments in a company: sales, finance, manufacturing, and system administrators. Each of these departments has a defined group and a set of users assigned to the group. Within the system administrators, there is one manager and three other administrators, each responsible for administering the resources of the other departments. The manager of the system administrators can perform any administrator action. Each of the other system administrators can only perform actions on members of the groups for which they are responsible.

The user name of the manager is mgr, the user names of the other system administrators are admin1, admin2, and admin3. The following commands illustrate the grants necessary for creating the example administration structure.

add member $admin mgr 
grant admin sales protect1 
grant admin admin1 protect1,all 
grant admin manufacturing protect2 
grant admin admin2 protect2,all 
grant admin finance protect3 
grant admin admin3 protect3,all 
You can grant a protection permission, in addition to the all permission. This signifies that the user has all administrator privileges for anyone who also has the same protection permission. However, if you revoke the all permission from a user, all permissions, including any protection permissions are removed from the access control list for the user.
  

An administrator is able to view users that have a different protection permission set, but the administrator can only perform actions on users with the same protection permission.

For example, admin1 can perform any action on any user in the sales group, and can view any users in the manufacturing or finance groups. However, admin1 is not able to grant permissions, change passwords, delete users from, or perform any other administrative action on users of the manufacturing or finance groups. The mgr user is able to perform any action on any user, regardless of their protection permission because mgr is a member of the $admin group.


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