Role-Based Access Control

The Role-Based Access Control (RBAC) section enables efficient management of user permissions across your organization by assigning users to groups, groups to roles and roles to permissions.

Role-Based Access Control (RBAC) centers on using a small set of rules to determine whether a particular user is permitted to perform an operation x on an object o. In the RBAC model, the constructs of groups and roles facilitate the efficient assignment of permissions to a potentialy large set of users. Groups aggregate users into a smaller number of entities, which are equivalent from an RBAC perspective, while roles bundle permissions into manageable units that can be assigned collectively, enabling users to carry out specific tasks. A permission, in this context, represents the combination of an operation with an object.

Regarding operations, the CDM RBAC model supports only two: READ and WRITE. Important: The permission to WRITE an object also allows to READ that object. A key aspect of permissions is efficiently defining sets of objects. The model takes advantage of the fact that objects within the IQ FMEA model can be organized as part of a vast family tree. Unlike a traditional family tree, however, the RBAC tree does not differentiate by gender—it simply consists of parent and child members.

Child members fall into two categories: some are intended to become parents themselves (e.g., business units), while others remain terminal (e.g., projects). In a conventional family tree, the structure starts with a progenitor. In contrast, the RBAC tree begins with a business unit representing the entire organization managed by the CDM server. From this root, children can either be parent elements (business units) or terminal elements (projects), allowing the tree to grow recursively to capture increasingly detailed levels of the organization.

In CDM RBAC roles need not be created globally but can be restricted to parts of the organization. Roles are created from Role templates and a member of the tree. Let’s assume your organization is divided into three departments called A, B and C whose common parent is the progenitor (member representing the organisation as a whole).

An abstract tree view of this organization called acme would look like the following diagram

CDM RBAC Role templates

The CDM RBAC provides three role templates:

1. Permission to write the member the template it is applied to and all its descendants; this Role-template is called Admin for short.
2. Permission to write all descendants of the associated tree member but not the associated member itself; this Role-template is called Editor for short.
3. Permission to read the member the template it is applied to and all its descendants; this Role-template is called Viewer for short.

Admin users and normal users

Users are classified into two categories based on the given rights at the specified level in the organization’s tree:

• Admin Users: These users have admin rights (write permissions) at the root level of the organization’s tree. Ony these users are allowed to create, modify or delete users, groups and roles.
• Non-Admin Users: These users lack write permissions on the root level of the organizational tree, restricting some functionalities and access to sections (see Roles page for more information).

A tour through RBAC of APIS CDM-Server functionality

You may create an Admin, an Editor and a Viewer role for department A (called Admin - A, Editor - A, Viewer - A). These three roles in isolation have no effect. You need to create groups in addition. Let’s assume you create three groups called AdminGroupA, EditorGroupA and ViewerGroupA and assign the AdminGroupA to role Admin of A, EditorGroupA to role Editor of A and ViewerGroupA to role Viewer of A. As the last step users are assigned to the three groups. Assuming 10 users work in department A, and you assign Chad and Julia to the AdminGroupA, John, Vitali, Manuel to the EditorGroupA Christoph, Andreas, Johannes and Conny to group ViewerGroupA. In addition there are two admins named Donald and Korbinian.

A user with administrator permissions

As a first step Korbinian logs into the Dashboard of the CDM-Server. After clicking on Business units he would see the following

Clicking on Roles and selecting the Admin - A role this is presented

And after clicking on Groups and selecting AdminGroupA this:

What effect will this have on the individual users after the login to the CDM-Server?

Admin role on a business unit

To answer this question Julia logs into the Dashboard and clicks on Business Units

Julia cannot see the Business Units B and C because she does not own Roles that gives her read permissions on those Business Units. But she can see Business Units acme and A and all descendants of A. She owns the Admin - A role which according to the definition above assigns write permissions for A and its descendants to Julia. Two additional rules of RBAC of CDM-Server are at play here that extends the permissions of Julia beyond those explicitly defined by the roles:

1. If a user owns write permissions on a member of the tree via the roles the user owns this user automatically gains read permissions on that member.
2. If a user owns read or write permissions on a member of the tree via the roles the user owns this user also gains read permissions on the ancestors of that member.

The first rule allows Julia to read A and all its descendants and the second rule allows Julia to read the acme node of the tree. If she clicks right on the Business Unit acme a context menu is shown

All potentially possible actions are shown but in this case each one is shown deactivated because Julia does not have write permissions on this tree node.

The context menu of Business Unit A

Here the picture is mixed. 3 actions are activated and 2 are deactivated. This situation relates to the third rule of RBAC of CDM-Server

3. The deletion or creation of a tree member is possible only if the user owns write permissions (a) on that member and (b) on the parent of that member.

Now Julia opens the context menu of Project a

As Julia owns the write permission on A all actions for non admin users are possible. Roles can only be created by admin users (see below).

You might miss the action ‘Create structure’ here. But this is beyond the functionality of the dashboard and is only offered by the APIS IQ-Software. The RBAC of CDM-Server is not restricting this.

Last but not least Julia right-clicks on the structure 1

Editor role on a business unit

Next Vitali logs into the Dashboard of the CDM-Server. He sees the same tree as Julia in the Business Units view. The context menu of acme is also identical but the context menu of A is different.

Vitali is in the EditorGroupA group which is connected to Role Editor - A. Recalling the definition of the Role template Editor above let’s you note that this role does not include WRITE permission on the tree node it is defined on. In combination with rule 3 it is evident that Vitali cannot use any action provided in the Dashboard on tree node A.

As follows from the discussion above the context menus for Project a and Structure 1 are identical to Julia’s.

Viewer role on a business unit

Finally Johannes logs into the Dashboard of CDM-Server.

The Business Unit view is the same as for Julia and Vitali. The context menus of all levels that Johannes can see will only contain deactivated actions because the only Role that Johannes owns is the Viewer - A Role. The description of the Role template Viewer specified that only READ permissions are given to a user by that role. Because all actions change some aspects of the data model, and therefore would need WRITE permissions, none of the actions is available if a user only owns READ permissions.

This ends the tour!

The major elements of RBAC of Apis CDM-Server have been presented. More information can be found in the sections on ID_PROVIDERs LOCAL, LDAP and Azure and special sections on Users, Groups and Roles.