This documentation supports the 20.02 version of BMC CMDB.To view an earlier version, select the version from the Product version menu.

Roles and permissions


You can assign users to groups and roles in the AR server to control users' access to the application based on the tasks they need to perform. If you are creating custom groups and roles and not using the default groups created when installing AR, the overall process of providing access has the following basic steps:

image2018-7-30_13-31-50.png

The process does not include the first step if you are using groups and roles that were automatically created during installation. 

Related topics

AR System: Creating users, groups, and rolesAR System: Regular, computed, and dynamic groupsAR System: Access controlAdding support staff in ITSM

Providing users with permissions to access the CMDB Portal by using groups and roles


Groups are permissions specific to a server while roles are used exclusively in applications. You must map a role to a group based on the level of access you wish to provide to that group.

image2018-7-31_14-21-20.png

Users

A user is any person to whom you give permission to access BMC CMDB. Users can be members of multiple groups or no group at all. Users in BMC CMDB range from an administrator who maintains the entire system to employees who only view data.

Groups

Groups are collections of BMC AR System users who are given access to perform specific tasks. Groups are specific to a server. A group has access to an object, a field, or a request, and any user added to that group inherits the same access. You can map a role to a group. You can also designate an entire group to be notified of a certain action. Installation of BMC AR System automatically creates some default groups and you can also define additional custom groups.

BMC AR System includes a public group and eight other special groups that are essential for access control within the system. You can define additional groups based on a common profile and assign access. For example, you might create a Sales group and allow members to view the status of a request but not to change it. A group can also be a general category, such as Browsers. 

Roles

Roles are permissions like groups, except that they belong to a particular application, instead of a particular server. Roles are used exclusively in deployable applications. Installation of applications such as ITSM automatically creates roles that you can later map to specific groups. You can also define roles when you need them.

You can map roles to different groups on different servers, depending on how the groups are defined on each server. This enables you to develop and test the application on one server and deploy it to many other servers without having to redefine permissions on each server. You can also map roles to different groups for each development state, such as testing or production.

image2019-9-18_9-48-10.png

Failed to execute the [excerpt-include] macro. Cause: [Error number 2 in 0: No wiki with id [confluencePage:page] could be found]. Click on this message for details.

Normalization and instance permissions

You can use the Normalization Engine to set the row-level permissions for specified classes and, with Remedy AR System qualifications, specific instances.

To use the Normalization Engine for instance permissions, you must complete the following steps:

  1. Define the rules for setting the row-level permissions. (See Creating-normalization-rules-to-set-row-level-permissions.)
  2. For each data set, enable the Row-Level Security feature. (See Configuring-normalization-settings-for-datasets.)

In addition to the CMDB Data View and CMDB Data Change roles, users must also have row-level access to instances. Each class has two attributes that specify users with read and write access to the class instances.


  • CMDBRowLevelSecurity — Users who are members of a group with row-level access have permission to view the instance if they also have the CMDB Data View or CMDB Data Change role.
  • CMDBWriteSecurity — Users who are members of a group with write access have permission to modify the instance if they also have row-level access and the CMDB Data Viewer role. This permission gives a user write access to a specific instance without giving write access to all instances with one of the CMDB Data Change roles.

You can define groups for the following permissions:

  • View — Members of these groups and roles can view the attribute in the class form, but cannot modify its value.
  • Change — Members of these groups and roles can view and modify the attribute value.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*