RBAC: Roles

• Role Inheritance
• Default Role
• Built-in Roles
• Role Properties
• Roles as Securable Resources
• Modifying Roles

Under role-based access control (RBAC), each user is assigned one or more roles, each of which holds some number of role-permissions. The set of permissions that apply to a user is then the set of all permissions held by at least one of the user's roles.

A role corresponds to the notion of a type of user, and captures the intuition that users of the same type will have the same degree of access to CodeSonar information and functionality. In general, the number of roles on a hub will be much lower than the number of users.

When you start a new hub, it will be set up with four built-in roles. You can modify these roles to various extents; you can also define as many new roles as you wish.

Role Inheritance

Each role can have any number of parent roles (including zero), and can be the parent of any number of other roles (including zero). A role may be directly assigned any number of role-permissions, and will also inherit the role-permissions of all its parents.

The remainder of this subsection uses an illustrated example to describe role inheritance in detail.

The following diagram shows one way that a set of roles {A, B, C, D, E, F, G} might be interrelated. Note in particular that there is no requirement that the roles all belong to a single overall hierarchy.

For the remainder of this discussion, we will concentrate on the example role hierarchy that contains roles {A, B, C, D}.

We say that:

• A is a parent of B; B and C are parents of D.
• A is an ancestor of B; A, B, and C are ancestors of D.
  (Conversely: B is a descendant of A; D is a descendant of A, B, and C.)
• A is an indirect ancestor of D.

The Role Ancestors page shows a role's parent roles and its indirect ancestor roles.

We say that a user who is directly assigned a role R is indirectly assigned all the roles that are ancestors of R.

We introduce two users to the example.

• User U is directly assigned role C. Since C has no ancestor roles, this does not entail any indirect role assignments.
• User V is directly assigned roles C and D, and is therefore indirectly assigned roles A, B, and C since these are the ancestors of D. User V is therefore assigned role C both directly and indirectly: this has no functional significance from the user's point of view, but does mean that an administrator who subsequently wishes to remove C from this user must take care to address both the direct and the indirect relationship.

The User Roles and Role Users pages show the user/role mapping from different perspectives. User Roles shows a user's directly and indirectly assigned roles; Role Users shows the directly and indirectly assigned users for a particular role.

We introduce three resource-permissions to the example: Q-1 (denoting permission 1 on resource Q), R-2, and S-3. To avoid cluttering the example with resource-inheritance relationships, we stipulate that all three involve resources of independent type, so can only be directly assigned or role-inherited.

• Role A is directly assigned resource-permission Q-1.
  Role A has no parent roles, so has no role-inherited role-permissions.
• Role B is directly assigned resource-permissions Q-1 and R-2. It also inherits Q-1 from its parent role A.
• Role C has neither direct nor indirect permissions.
• Role D is directly assigned resource-permission S-3. It also inherits Q-1 and R-2 from its parent role B.

The Global Role-Permissions page and Resource Role Permissions pages show both direct and and indirect permissions for each role.

The full picture is therefore as follows.

• User U has no permissions.
• User V has resource-permissions Q-1, R-2, and S-3. Of these, S-3 is a direct resource-permission and the other two are role-inherited.

Default Role

One of the assigned roles for each user is designated the default role for that user. A user's default role is used to establish the initial role-permission assignments for new independent resources created by that user.

• Enabled cannot be the default role for any user.
• If a user's default role is removed from their set of assigned roles, their default role is set to Anyone.
• If a user's default role is deleted from hub, their default role is set to Anyone.

To set the default role...

• ...for your own hub user account, use the Account tab of a Settings page.
• ...for another hub user account, use the Account Settings tab of the Account Editor for that account. (Requires G_ADMINISTER_USERS permission.)

Built-In Roles

CodeSonar ships with five roles: Administrator, Manager, Anyone, Enabled, and User. Of these, Administrator, Anyone, and Enabled have special protections: they cannot be deleted or renamed.

Each of these roles is assigned a set of default role-permissions when a new hub is created. These assignments can be adjusted subsequently, except that the immutable role-permissions for each role cannot be removed.

Role Properties

Roles have the following properties.

Roles as Securable Resources

Roles are securable resources, with access controlled by the ROLE_* permissions. It is therefore possible to grant permission to edit role-permission and user assignments for individual roles, without needing to assign the G_ADMINISTER_USERS permission.

For example, suppose a hub has a project called ProjectA, with a role called ProjA that provides access to ProjectA and is assigned to all users who are working on that project. To delegate assignment/unassignment of the ProjA role to someone who does not have the special Administrator role, an administrator might create a new role called ProjAManager and assign it permission ROLE_ASSIGN for ProjA. When a new user starts working on ProjectA, anyone with the ProjAManager role can assign them the ProjA role without needing to go through a hub administrator. Similarly, if a user stops working on Project A, anyone with the ProjAManager role can remove ProjA from the user's set of assigned roles.

Modifying Roles

CodeSonar provides the following operations on roles.

[*] "Changing a user's role set" and "changing a role's user set" represent two perspectives on the same underlying operation: changing the mapping between users and roles. Similarly, the Role Users and User Roles page types provide dual views of that mapping. You can use either page type to change user/role assignments: in general, choose Role Users if you are focused on a particular role and User Roles if you are focused on a particular user.