Red Hat Training
A Red Hat training course is available for Red Hat JBoss Operations Network
6. Managing Roles and Access Control
In JBoss Operations Network, security is implemented through rules that are set on users and roles. Restrictions are set on what users and roles can access and what operations they can perform.
6.1. About Security in JBoss ON: Roles and Access Control
In JBoss Operations Network, security is achieved by establishing precise relationships between users, resources, and the tasks users can perform. Interactions between users and resources are ordered by including or excluding those users and resources (through groups) in defined roles, and then granting the role the ability to perform tasks.
When a user is allowed to perform a certain operation, that is called a permission. All permissions must be explicitly granted to explicit resources. If a user is not given permission to a specific resource group, then the user, by default, has no access to that group — even if the user has permission to perform a task. Likewise, if a user has access to a group but has no permissions assigned, then the user cannot perform any tasks.
Any permissions set in JBoss ON are given to a role, and the members of the role inherit those permissions. Allowing or restricting permissions is access controls.
In JBoss ON, there are two categories where access control is given:
- Global permissions apply to JBoss ON server configuration. This covers administrative tasks, like creating users, editing roles, creating groups, importing resources into the inventory, or changing JBoss ON server properties.
- Resource-level permissions apply to actions that a user can perform on resources in the JBoss ON inventory. These cover actions like creating alerts, configuring monitoring, and changing resource configuration. Resource-level permissions are tied to the subsystem areas within JBoss ON.
All JBoss ON permissions are listed in Table 9, “JBoss ON Access Control Definitions”.
For resource-level rights, all of the rights granted are explicit modify rights. This means that giving the right allows users to do something on the resource. For the most part, the ability to view that area (read rights) are granted implicitly. For example, any user can view the operations history of a resource or view the configured alerts for a resource within the role even if that role has not been given edit access to those subsystem areas. The read access is implied. There is one exception to that rule: resource configuration. Resource configuration can be considered a security risk, and some administrators may want to restrict read access to configuration. If write access is given to resource configuration, then read access is automatically granted. However, read-only access must be explicitly granted to a role; otherwise, read access is denied by default.
Figure 32. Read Access Option
Note
Granting a role the right to change something does not implicitly grant the right to delete something. For example, users with the configuration write permission can edit resource configuration and view configuration history and settings, but they cannot delete elements in the configuration history. Similar constraints are true for users with permission to create and edit operations and alerts — there is no right to delete elements in the resource history.
Deleting elements in the history requires the manage inventory permission.
Table 9. JBoss ON Access Control Definitions
| Access Control Type | Description |
|---|---|
| Global - Security | Equivalent to a superuser. Security permissions grant the user the rights to create and edit any entries in JBoss ON, including other users, roles, and resources, to change JBoss ON server settings, and to control inventory.
Warning
The Security access control level is extremely powerful, so be cautious about which users are assigned it. Limit the number of superusers to as few as necessary.
|
| Global - Inventory | Allows any operation to be performed on any JBoss ON resource, including importing new resources. |
| Global - Settings | Allows a user to add or modify any settings in the JBoss ON server configuration itself. This includes operations like deploying plug-ins or using LDAP authentication. |
| Global - Bundles | Allows a user to upload and manage bundles (packages) used for provisioning resources. |
| Global - Repositories | Allows a user to access any configured repository, including private repositories and repositories without specified owners. Users with this right can also associated content sources with repositories. |
| Resource - Modify | Allows a user to change the resource definition entry in JBoss ON. This does not grant rights to edit the resource configuration. |
| Resource - Delete | Allows the user to delete the resource from the inventory. |
| Resource - Create Child | Allows the user to manually assign a child resource to another resource. |
| Resource - Alerts | Allows the user to create alerts and notifications on a resource. Configuring new alert senders changes the server settings and is therefore a function of the global Settings permissions. |
| Resource - Measurements | Allows the user to configure monitoring settings for the resource. |
| Resource - Content | Allows the user to manage content providers and repositories that are available to resources. |
| Resource - Control | Allows a user to run operations (which are also called control actions) on a resource. |
| Resource - Configure | Allows users to change the configuration settings on the resource through JBoss ON.
Note
The user still must have adequate permissions on the resource to allow the configuration changes to be made.
|
JBoss ON handles access to both resources and JBoss ON configuration through roles. A role has certain permissions assigned to it, meaning things that members of the role are allowed to do.
Only two types of JBoss ON identities can belong to a role: users and groups.
Users are assigned to a role to be granted those permissions. Users can be added to a role individually or be added as a member of an LDAP group.
Resource groups are assigned to a role to provide a list of resources that those users can perform actions on. Another way of looking at it is that users can only manage resources that they are expressly given access to. Roles define that access.
Note
Be sure to create resource groups to assign to any custom roles you create. If no resource groups are assigned to a role, then none of the members of the role can see any resources. Creating groups is described in Section 4.3, “Creating Groups”.
One convenient feature of roles is that users can be automatically assigned to roles by assigning an LDAP group to the role (Section 7.5, “Associating LDAP User Groups to Roles in JBoss ON”). All of the LDAP users who belong to that group are automatically members of the role. (This is similar to the simplicity of using LDAP user to create JBoss ON users by enabling LDAP authentication, in Section 7.3, “Configuring LDAP User Authentication”.)
There are two roles already configured in JBoss ON by default:
- A superuser role provides complete access to everything in JBoss ON. This role cannot be modified or deleted. The user created when the JBoss ON server was first installed is automatically a member of this role.
- An all resources role exists that provides full permissions to every resource in JBoss ON (but not to JBoss ON administrative functions like creating users). This is a useful role for IT users, for example, who need to be able to change the configuration or set up alerts for resources managed by JBoss ON but who don't require access over JBoss ON server or agent settings.
6.2. Creating a New Role
Note
Be sure to create resource groups to assign to any custom roles you create. If no resource groups are assigned to a role, then none of the members of the role can see any resources. Creating groups is described in Section 4.3, “Creating Groups”.
- Create any resources groups which will be associated with the role. Creating groups is described in Section 4.3, “Creating Groups”.By default, JBoss ON uses only resource groups to associate with a role, and these are required. However, optional user groups from an LDAP directory can also be assigned to a role, so that the group members are automatically treated as role members. LDAP groups must be configured in the server settings, as described in Section 7.5, “Associating LDAP User Groups to Roles in JBoss ON”.
- In the top menu, click the Administration tab.
- In the menu table on the left, select the item.
- The list of current roles comes up in the main task window. Click the button at the bottom of the list.
- Give the role a descriptive name. This makes it easier to manage permissions across roles.
- Global permissions grant permissions to areas of the JBoss ON server and configuration.
- Resource permissions grant permissions for managing resources.
The specific access permissions are described in Table 9, “JBoss ON Access Control Definitions”.
Move the required groups from the Available Resource Groups area on the left to the Assigned Resource Groups on the right as required.- At the bottom, click the button.
- Select the Users tab to assign users to the role.
Move the required user from the Available Users area on the left, to the Assigned Users on the right as required. - Click the arrow in the upper right to close the create window.
6.3. Editing Roles
All of the role configuration — including the access rights set for the roles and the groups and users assigned to the role — can be changed after the role is created. The edit options for a role are exactly the same as the creation options in Section 6.2, “Creating a New Role”, even to changing the name of the role.
- In the menu table on the left, select the item, and click the name of the role to edit.
- Go through the role's tabs and change the configuration as desired.
