Permission Management Overview
The Execution Management System provides a comprehensive permission management system that allows defining permissions on the member level or on the role level in a coarse or granular fashion.
This document will explain the different granularities (application, container, or object), and how groups can be used to achieve role-based access control (RBAC). Finally, we will showcase frequent setups.
Permission granularities
Permissions can be set in coarse, medium, and fine granularity.
Coarse would correspond to application-level permissions.
Medium would correspond to container-level permissions.
Fine would correspond to object-level permissions
An application such as Process Analytics uses containers to organize its objects.
The objects live inside these containers:
 |
Process Analytics, containers are called Workspaces and objects are the Analyses.
In Data Integration, containers are called Data Pools and objects are referred to as Data Models.
For instance, you might want to award a group of members to administrate all data models via "EDIT ALL DATAPOOLS".
Application Level
Permissions on the application level are only available for team admins, and thus accessible in Admin and Settings
They can define which groups or members are awarded general permissions to do anything inside containers or objects.
 |
Container level
Permissions on the container level are awarded via the context menu on the container (the three dots).
These container-level settings are documented on each application page:
 |
Object Level
Permissions on the object level are set on the object itself, via the context menu (the three dots).
 |
Role-Based Access Control
Role-Based Access Control, or RBAC for short, allows defining a set of roles.
These roles are awarded permissions to perform certain actions.
Users can have one or more roles, and authorized by their role can then perform simple actions.
This setup has a huge advantage: It scales since individual permissions become obsolete.
Roles in the EMS
The user part of the EMS licensing model has two parts: a members and an analyst limit.
Anybody who is a team member has to have one of the three following roles:
Member - view content depending on permissions
Analyst - create / view / edit / delete content depending on permissions
Admin - create / view / edit / delete all content and administrate the team
All team members count towards the member limit, while analysts and admins also count toward the analyst limit.
Pay close attention to terminology
In the EMS, the term role is used to highlight the level that a user has. This has license reasons. Please see to the right what the user roles are.
It is not to be confused with the roles that you define to be used by your team members.
RBAC in the EMS is achieved via groups which you can regard as roles in the traditional sense
Example setups
These examples showcase a few RBAC setups, using Groups to realize the role.
Example setup 1
Desired state: There should be two different projects. Nobody in one project should be able to see or use anything from the other project. A project in this context could also mean a department or subsidiary.
Role Name | Role Description |
|---|---|
Viewer | This role should only allow viewing content. |
Analyst | This role can do all of the above, plus edit and create content. No access to anything else though. |
Data Engineer | This role can do all of the above, plus manage the data pipeline. |
Admin | This role can do all of the above, plus manage team-wide settings and permissions |
How to realize this in the EMS: The roles are implemented as groups in the EMS. The admin role permits seeing and manipulating everything inside a team. It does not make a lot of sense to have an administrator who can change settings that affect the whole team, but who can only see half of the content.
Role name Group name | Group role | Group Permissions |
|---|---|---|
Project1_Viewers | Viewer | Process Analytics - Project 1 Workspace: USE ALL |
Project1_Analysts | Analyst | Process Analytics - Project 1 Workspace:
|
Project1_DataEngineers | Analyst | Data Integration - Project 1 Data Pool:
Process Analytics - Project 1 Workspace:
CREATE ANALYSES EDIT ALL ANALYSES EDIT WORKSPACE DELETE ALL ANALYSES |
Project2_Viewers | Viewer | Project 2 Workspace: USE ALL |
Project2_Analysts | Analyst | Project 1 Workspace:
|
Project2_DataEngineers | Analyst | Data Integration - Project 2 Data Pool:
Process Analytics - Project 2 Workspace:
CREATE ANALYSES EDIT ALL ANALYSES EDIT WORKSPACE DELETE ALL ANALYSES |