Task: Modify a Role's Permissions

• Overview
• Permissions Needed For This Task
• Determine Elements of Interest
• Add and Remove Direct Permissions
• Adjust Role Inheritance
• Links

Overview

Hub user accounts (including special user Anonymous) get their permissions from their assigned roles. To adjust the permissions that apply to a user you therefore have two options:

• Modify the user's assigned role set by adding or removing one or more roles.
• Adjust the role-permissions for one or more of the user's assigned roles.

This page describes the steps required for the second of these options: adjusting the role's permission set.
For the first option, see Task: Modify a User's Roles.

There are two ways to modify a role's permission set, both of which are covered here.

• Adjust the set of directly-assigned permissions for the role.
• Adjust the role's parent set.

Note that some of the role-permissions for special roles Enabled, Anyone, and Administrator are immutable. You will not be able to remove the immutable permissions from those roles.

Permissions Needed For This Task

You will need to be authenticated as a user with the necessary permissions.

It is sufficient to authenticate as a user with the special Administrator role, which immutably has the necessary permissions. In particular, it is always sufficient to authenticate as special user Administrator.

Determine Elements of Interest

Before you adjust the permissions for some role R, you will need to make several determinations.

1. Which permissions you wish to add and remove: Determine Permissions of Interest.
2. If you are removing permissions, whether this entails removing parent roles from R (and if so, which parents): Determine Parent Roles to Remove.
3. If you are adding permissions, whether this is best accomplished by adding parent roles to R (and if so, which roles): Determine Parent Roles to Add.

Determine Permissions of Interest

For global permissions, which do not apply to specific resources, a role-permission is a single rule assigning one G_* permission to one role.

In all other cases a role-permission is a single rule assigning one resource permission to one role for one resource. The permission must be applicable to the resource.

Before adding or removing direct role-permissions, you will therefore need to decide:

• which resources you are interested in, and
• which permissions you wish to assign to those resources.

If you are not sure about the purposes of the various permission types, inspect the manual section about permissions, especially the recommended permission combinations.

In choosing your resources of interest, remember that some resource types are hierarchical and permissions on resources of those types can be either direct or indirect . For example, you can directly apply an ANALYSIS_* permission to any of the following.

• A single analysis A.
• A project P, so that the permission indirectly applies to all analyses of P.
• A project tree T, so that the permission indirectly applies to all analyses of all projects under T.

Determine Parent Roles to Remove

Suppose you have some role R, and a set of permissions that you wish to remove from R. If R has an existing parent role T that holds all (or a coherent subset) of those permissions, you will need to either remove T from R's parent set or remove those permissions from T.

To identify these cases, you will need to inspect the role-permission assignments for all parents of R. Keep a mental note of your candidate roles for deletion. Initially this set is empty; you will add roles to the set as you identify parent roles that hold permissions that you wish to remove from R.

1. If the CodeSonar Web GUI is not already open, open it now.
2. If you are currently signed into a user account that does not have sufficient permissions for this task:
   1. Sign out: click your username in the GUI page header , then click the Sign Out link that pops up.
   2. Click the Sign In link in the GUI page header:
      The Sign In page will open.
   3. Sign back in as Administrator (or another user with sufficient permissions):.
3. Navigate to the Role Ancestors page for R.
   1. Navigate to the Roles page.
      1. Click the Settings icon in the page header to view the Settings page.
      2. Select the User Administration tab.
      3. Click Roles.
         The Roles page will open.
   2. Click the table row for R.
      The Role Users page for R will open.
   3. Click the Ancestor Roles tab.
      The Role Ancestors page for R will open.
4. Identify the immediate parents of R: the roles with "parent" checkmarks in the Is Ancestor column.
5. Navigate to the Global Role-Permissions page.
   1. Click the Settings icon in the page header to view the Settings page.
   2. Select the User Administration tab.
   3. Click Global Permissions.
      The Global Role-Permissions page will open.
6. Inspect the rows for the roles that are immediate parents of R. If any of them have global permissions that you wish to remove from R, add them to your candidate roles for deletion set.
7. If you are also interested in resource role-permissions, inspect the relevant Resource Role-Permission pages.
   For example, suppose you are interested in permissions with respect to the project called ProjectX. Then:
   1. Navigate to the Project page for ProjectX.
      (For detailed navigation instructions, see Task: View Information About a Project.)
   2. Expand the Project Details section of the page.
   3. Click the Permissions link at the top of the Project Details section.
      The Resource Role-Permissions page for ProjectX will open.
   4. Inspect the table rows corresponding to the immediate parents of R. Add roles to the candidate roles for deletion set if they have permissions that you wish to remove from R.
8. If you have identified a nonempty set of parents to remove from R, go on to Adjust Role Inheritance.
   Otherwise, you will only need to remove permissions directly: go on to Add and Remove Direct Permissions.

Determine Parent Roles to Add

Suppose you have some role R, and a set of permissions that you wish to add to R. If there is already a role S that holds all (or a coherent subset) of those permissions, it may make sense to make S a parent of R so that R can inherit S's permissions indirectly rather than directly assigning those permissions to R.

There are two factors involved in making this determination:

• Whether there exist any roles with appropriate permission assignments.
  To make this determination, you will need to inspect the role-permissions assignments for existing roles.
  • Always evaluate the global role-permissions. These permissions determine the degree of access a user has to hub administration functionality as well as to fundamental functionality such the ability to sign in.
  • In some cases, you may also be interested in resource-specific role-permissions. For example, you may wish to make sure that a user is able to view information about analyses of a particular project.
• Whether a particular parent-child relationship between roles makes semantic sense.
  This determination will depend on the set of roles you are using on your hub and the meaning you have associated with each role.

To evaluate the available roles and determine a set of candidate parents for role R, proceed as follows.

1. If the CodeSonar Web GUI is not already open, open it now.
2. If you are currently signed into a user account that does not have sufficient permissions for this task:
   1. Sign out: click your username in the GUI page header , then click the Sign Out link that pops up.
   2. Click the Sign In link in the GUI page header:
      The Sign In page will open.
   3. Sign back in as Administrator (or another user with sufficient permissions.
3. Navigate to the Global Role-Permissions page.
   1. Click the Settings icon in the page header to view the Settings page.
   2. Select the User Administration tab.
   3. Click Global Permissions.
      The Global Role-Permissions page will open.
4. Inspect the table of global role-permission assignments to identify suitable roles, if any. We will refer to these roles as your candidate roles for addition.
5. If you are also interested in resource role-permissions, inspect the relevant Resource Role-Permission pages.
   For example, suppose you are interested in permissions with respect to the project called ProjectX. Then:
   1. Navigate to the Project page for ProjectX.
      (For detailed navigation instructions, see Task: View Information About a Project.)
   2. Expand the Project Details section of the page.
   3. Click the Permissions link at the top of the Project Details section.
      The Resource Role-Permissions page for ProjectX will open.
   4. Inspect the table rows corresponding to your current candidate roles for addition. Drop roles from the candidate set if they have permissions that you do not wish to assign to R.
      You may also decide to drop roles from the set if they are missing permissions that you wish to assign to R, but this is not an absolute requirement: you can always assign those permissions to R explicitly.
6. If any roles remain in your candidate set, decide whether any of them are suitable parents for R. Note the following.
   • A role may have a reasonable set of permissions but still not make sense as a parent for R: your decision will need to take your semantic model of the hub's role set into account.
   • You can assign as many parent roles as you wish (including none).
   • Some or all of the roles in the candidate set may be in parent-child relationships with one another. To view these relationships, look at each role's Role Ancestors page.
     1. Click Roles in the link bar to navigate to the Roles page.
     2. Click the table row for the role you are interested in.
        The Role Users page will open.
     3. Click the Ancestor Roles tab.
        The Role Ancestors page will open.
     4. Examine the table of ancestor roles to identify the roles with "parent" checkmarks in the Is Ancestor column.
7. If you have identified a nonempty set of parents to assign to R, go on to Adjust Role Inheritance.
   Otherwise, you will need to add permissions directly: go on to Add and Remove Direct Permissions.

Add and Remove Direct Permissions

Suppose you wish to adjust the role-permission assignments for role Engineer, and you already know:

• That you wish to adjust Engineer's direct role-permission assignments.
• Which permissions you want to add/remove, and for which resources.
  If you haven't already done so, check the recommended permission combinations for the permissions you have chosen in case additional permissions are advised.

If you have not yet made these determinations, see Determine Elements of Interest, above.

1. If the CodeSonar Web GUI is not already open, open it now.
2. If you are currently signed into a user account that does not have sufficient permissions for this task:
   1. Sign out: click your username in the GUI page header , then click the Sign Out link that pops up.
   2. Click the Sign In link in the GUI page header:
      The Sign In page will open.
   3. Sign back in as Administrator (or another user with sufficient permissions).
3. Make your desired adjustments to global role-permissions for Engineer:
   1. Navigate to the Global Role-Permissions page.
      1. Click the Settings icon in the page header to view the Settings page.
      2. Select the User Administration tab.
      3. Click Global Permissions.
         The Global Role-Permissions page will open.
   2. In the Engineer row of the table, deselect the global permissions you wish to remove and select the global permissions you wish to add.
   3. Click Save Changes (under the table).
      The page will reload and the table contents will be updated.
4. Make your desired adjustments to resource role-permissions for Engineer. For each resource of interest:
   1. Navigate to the corresponding Resource Role-Permissions page.
      For example, suppose you wish to adjust Engineer's permissions for the project called ProjectX. Then:
      1. Navigate to the Project page for ProjectX. (For detailed navigation instructions, see Task: View Information About a Project.)
      2. Expand the Project Details section of the page.
      3. Click the Permissions link at the top of the Project Details section.
         The Resource Role-Permissions page for ProjectX will open.
   2. In the Engineer row of the table, deselect the resource permissions you wish to remove and select the resource permissions you wish to add.
   3. Click Save Changes (under the table).
      The page will reload and the table contents will be updated.

Adjust Role Inheritance

Suppose you already know:

• That you wish to adjust the set of parent roles for role Engineer.
• Which parent roles you want to add/remove.

If you have not yet made these determinations, see Determine Elements of Interest, above.

1. If you are currently signed into a user account that does not have sufficient permissions for this task:
   1. Sign out: click your username in the GUI page header , then click the Sign Out link that pops up.
   2. Click the Sign In link in the GUI page header:
      The Sign In page will open.
   3. Sign back in as Administrator (or another user with sufficient permissions).
2. Navigate to the Role Ancestors page for Engineer.
   1. Navigate to the Roles page.
      1. Click the Settings icon in the page header to view the Settings page.
      2. Select the User Administration tab.
      3. Click Roles.
         The Roles page will open.
   2. Click the table row for Engineer.
      The Role Users page for Engineer will open.
   3. Click the Ancestor Roles tab.
      The Role Ancestors page for Engineer will open.
3. In the table of roles, click the Assigned checkboxes to add and remove parent roles for Engineer.
   Note that you will only be able to directly remove immediate parents.
4. Click the Save Changes button (under the table).
   The table will be updated to show the new set of parent roles.

Links

• Typical CodeSonar Tasks
• The CodeSonar Hub
• Role-Based Access Control