Roles and Permissions
Privileges to perform actions and operations in Admin UI are based on the role and permissions granted to the user.
Roles
Administrators use roles to allot permissions in Admin UI. When a role is assigned to a user or a group, the user or group receives all the permissions granted to the role.
The following roles are defined in Admin UI: BW User, BW Operator and BW Administrator.
Permissions
- Entity Based - Permission can be enforced on the complete entity such as a domain, AppSpace and so on. For example, for two domains d1 and d2, if the read permission is granted to the domain entity, you can view both the instances, d1 and d2.
- Instance Based - Permission can be enforced on a particular instance of an entity. For example, if the read permission is granted for the d1 instance of the domain entity, you have permission to view only d1.
Types of Permissions
- Read: Read permission for the entities.
- Lifecycle: You can grant lifecycle permission to a user only if he has explicit read permission. Lifecycle permission is applicable only to AppSpaces, AppNodes, and applications, to control the lifecycle of entities such as AppSpaces, AppNodes, and applications (that is to start and stop the entities)
- Full_control: By default, this permission includes the read permission. Entities can perform the following commands with the full control access:
Entity-Based Permissions
To add the ActiveMatrix BusinessWorks™ product under the list of Products on the Admin UI homepage, select the following entities on the Add Permission page.
Entity Hierarchy for Instance-Based Permission
The hierarchy of entities when granting permissions in Admin UI is illustrated in the following image. Domain is the top-level parent entity and includes AppSpaces and Archives. AppSpaces then further include AppNodes.
Granting Instance-Based Permissions
Scenario 1: Instance-based permission assigned to a child entity
When an instance-based permission is assigned to a child entity, the read permission is assigned to the parent entity if the parent does not have any permissions assigned. The administrator can, however, update the permission assigned to the parent. The updated permission is then enforced.
Scenario 2: Instance-based permission assigned to a parent entity
When an instance-based permission is assigned to a parent entity, the permission is not applied to the child entity. Permissions for the child entities can be assigned explicitly. For example, if the read permission is applied to AppSpace1, the child entities of AppSpace1 do not inherit the permission.
Example of how entity-based and instance-based permissions work
Objective
Appspace a1 contains two AppNodes, n1 and n2. AppSpace a1 is a child entity of Domain d1. Grant permissions so that you can only view AppNode n1 and start and stop AppNode n2.
- From the entity permission page, Add Permission, provide read permissions to the entities BusinessWorks and bwagents. They are the top level entities and are mandatory to view the TIBCO ActiveMatrix BusinessWorks™ product.
- Provide entity-based permission to domains, AppSpaces and AppNodes. It is mandatory to provide permission for plural entities such as domains and AppSpaces, to view the content on these pages.
- Provide instance-based permission to AppNode n1 and lifecycle and read permission to AppNode n2.
The following section explains how the permissions granted in the example work:
- For Domain d1 to be visible, grant permissions to the entities BusinessWorks, bwagents, domains and for the instance of the domain d1.
- For AppSpace a1 to be visible, grant permission to the entities BusinessWorks, bwagents, domains, AppSpaces and for the instance a1. Explicit permissions are not required to be given to Domain d1. Parents entities are provided view permission automatically.
- For AppNode n1 to be visible grant permission to the entities BusinessWorks, bwagents and domains, AppSpaces and AppNodes and for the instance a1.
Additional Notes
- Actions taken on parent level transcends the actions taken on the child entity even if you do not have access to the child entity. For example, If you start and stop an AppSpace, all the AppNode in this AppSpace start and stop even if you do not have access over all of the AppNodes.
- Custom users cannot view any new entity they create as these users do not have instance based permission for that entity. For example, you have full control access to an Appspace and you navigate to the AppSpace page and use the Create button to create a new AppSpace a2. Users will not be able to view AppSpace a2 as they do not have access permissions for a2. The administrator will have to grant permissions to access this AppSpace to enable custom users to see it. This is applicable to all entity types.
- While taking a backup of a domain, all entities within this domain will be backed up irrespective of the permissions granted.
- The Appnodes, Appspaces and Application Archives count can be seen on the Domain Management Page irrespective of permissions granted to the user.