This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Role-Based Access Control

How to manage users, groups, roles and permissions

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.

Overview

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

Demo tree

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

Admin view business units

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

Admin view roles Admin A

And after clicking on Groups and selecting AdminGroupA this:

Admin view groups AdminGroupA

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 view BusinessUnits

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

Julia view BusinessUnit acme Context menu

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

Julia view BusinessUnit A Context menu

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

  1. 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 Julia view Project small a Context menu

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 Julia view Structure 1 Context menu

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 view BusinessUnit A Context menu

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.

1 - Users

CDM-Server Users as part of the RBAC

The Users Management is the essential first step in defining and organizing access permissions, as all subsequent groups, roles and permissions rely on the accurate setup of user accounts.

Regardless of the chosen ID Provider, configuring users in the User Management section establishes the essential foundation for RBAC (Role-Based Access Control), enabling robust, secure, and scalable access control across the system.

How Users integrate with RBAC

By establishing users first, the organization can easily assign them to groups and later link these groups to roles as needed, creating a scalable, manageable RBAC hierarchy.

Typical Workflow

  • User Registration: Users are created or imported from an external source (LDAPS or Azure). This provides a central repository for user accounts.
  • Assign Users to Groups: Once added, users are assigned to Groups. Groups are logical collections of users with similar access requirements, such as departments, teams, or project members.
  • Link Groups to Roles: Groups are then connected to Roles. Roles define the specific permissions for each group, streamlining the process by allowing permissions to be assigned collectively rather than individually.

For detailed guidance on managing users, visit the Users page.

2 - Groups

CDM-Server Groups as part of the RBAC

The Groups Management is a central component in the system’s Role-Based Access Control (RBAC) in the CDM-Server. It enables administrators to create, edit, view, and delete Groups—the critical link between users and roles. By assigning users to groups, and then associating those groups with roles, you can efficiently manage permissions across the organization without needing to configure each user individually.

How Groups integrate with RBAC

Groups act as a bridge between users and roles. By defining permissions at the group level, administrators can simplify access control, making it easier to manage permissions for multiple users at once.

Typical Workflow

  • Create a Group: Define a new group and specify its purpose (e.g., “Project Managers” or “Quality Assurance”).
  • Assign Users: Add users to the group who need similar access levels.
  • Associate Roles: Link the group to specific roles that define permissions.
  • Review and Adjust: Regularly view and update group memberships and role associations as team compositions change.

For detailed guidance on managing groups, visit the Groups page.

3 - Roles

CDM-Server Roles as part of the RBAC

The Roles Management section is the final and essential piece of the Role-Based Access Control (RBAC) in the CDM-Server.

Roles define specific permissions within the system, determining what actions can be taken and what resources can be accessed by groups and their members. Roles are the end-point in the RBAC hierarchy, serving as the permission layer that applies to users indirectly through their assigned groups.

How Groups integrate with RBAC

In the CDM-Server there are 3 predefined Role Template s which already have specific permissions:

  • Admin: Grants full write permissions on the selected level within the organization’s tree, including all subordinate levels. Admin users have complete control over the selected node and any of its child nodes, allowing them to modify, add, or delete resources.
  • Editor: Provides write permissions ONLY on the child nodes of the selected level within the organization’s tree. Editors can modify content and make updates at subordinate levels without altering permissions or resources at the main (selected) level, preserving the structure while enabling focused updates.
  • Viewer: Offers read-only access on the selected level within the organization’s tree, including all subordinate levels. Viewers can view resources and data within these levels but cannot make any changes, ensuring secure and restricted access for users who need visibility without modification rights.

Typical Workflow

  • Create a Role: Define a new role by selecting the Role Template and level in the organization’s tree (Business Unit or Project).
  • Assign Groups: Add groups to the role.
  • Review and Adjust: Regularly view and update group and role associations as team compositions change.

For detailed guidance on managing roles, visit the Roles page.