Roles and permissions
You can assign users to groups and roles in the AR System 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 System server, the overall process of providing access has the following basic steps:
The process does not include the first step if you are using groups and roles that were automatically created during installation.
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.
Users
A user is any person to whom you give permission to access BMC Helix CMDB. Users can be members of multiple groups or no group at all. Users in BMC Helix CMDB range from an administrator who maintains the entire system to employees who only view data.
Groups
Groups are collections of 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 AR System automatically creates some default groups and you can also define additional custom groups.
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 BMC Helix 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.
Permissions model to provide access to the new CMDB Portal
Based on the groups users are assigned to, the features they can access varies. The AR System server groups referenced in the following table are created automatically when you install BMC Helix CMDB and BMC Helix ITSM:
Persona and their requirements | Access level in the new CMDB UI | Groups to which you can assign the user | |
|---|---|---|---|
BMC Helix CMDB only | BMC Helix CMDB with BMC Helix ITSM | ||
Administrator Requires all features of the CMDB Portal. | All areas of BMC Helix CMDB | Administrator (Fixed license) | Not applicable |
CMDB configuration manager Requires all features of the CMDB Portal except those which are related to Atrium Integrator. | All of the CMDB Portal except the following:
| RE Definition Author (Floating license) | Not applicable |
CMDB data publisher Performs asset related work, creates and edits CIs and other activities related to service modeling. Requires access to Search and the CMDB Explorer in the CMDB Portal and also needs to be able to edit CIs in the CMDB Explorer. |
Important: An Asset Admin additionally requires RE Definition Author permission for unrestricted access to all CMDB pages in CMDB Portal. | CMDB Data Change Group
| Asset Admin (Floating license) |
CMDB user Perform asset related work. Needs to only access the Search and the Explorer in the CMDB Portal. Does not need to edit CIs in the CMDB Explorer and cannot create or edit CIs. | Can access only CMDB Explorer in CMDB Portal with at least Asset User or Asset Admin permissions. | CMDB Data View Group | Minimum level of access required: Asset User.
In addition, you can assign the following groups: Task Manager, Task User, Task Viewer, Asset Viewer, Asset Config, Infrastructure Change Master, Infrastructure Change User, Infrastructure Change Submit, Infrastructure Change Viewer, Infrastructure Change Config, Release Master, Release User, Release Viewer, Activity User, Activity Viewer, Release Config, Activity Config, Incident Master, Incident User, Incident Viewer, Incident Config, Problem Master, Problem User, or Problem Viewer |
Normalization and instance permissions
You can use the Normalization Engine to set the row-level permissions for specified classes and, with AR System qualifications, specific instances.
To use the Normalization Engine for instance permissions, you must complete the following steps:
- Define the rules for setting the row-level permissions. (See Creating-normalization-rules-to-set-row-level-permissions.)
- 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.