Groups, Roles and Permissions
- PIPEFORCE
SINCE VERSION 1.0
Introduction
Permissions in PIPEFORCE are also called roles. With such roles, you can define what a user is allowed to do. Roles can be assigned directly to a user or to a group via the webui of the IAM or the iam.* commands. Furthermore, there are also roles which define a set of other roles. These parent roles are called composite roles.
Note that you need to be a member of ROLE_ADMIN or ROLE_DEVELOPER in order to be able to change role permissions as described in this chapter. In case you’re not able to login into IAM or apply the steps described below, please contact the PIPEFORCE admin in your company or feel free to contact our support team to grant you the required permissions and roles.
What is a Role (Permission)?
In PIPEFORCE, there is the concept of roles. A role can be seen as a permission (privilege) for a user to be allowed to do a certain task in the system. A role is a permission: So whenever you see a role, it can also be called a permission, and vice versa. These names are equal.
Roles can be assigned to a single user or group. A user will be granted all roles of all groups he is a member of.
It is a good practice to assign roles via groups, instead of directly to users.
The main difference between roles and groups is that roles cannot be created or deleted by admins. These are “factory default” roles and some roles are created by app developers.
Roles can also contain other roles. Such parent roles are called Composite Roles. You probably never require such type of roles, since they are mainly used in PIPEFORCE internally only.
Default Roles (ROLE_)
These composite roles exist by default in PIPEFORCE and cannot be removed (“factory defaults”). Any user or group, which is assigned to such a role, has some additional basic set of permissions assigned to fulfill a certain role in PIPEFORCE.
Role Name | Description |
| Any guest user of PIPEFORCE is assigned to this role. Guest users do not require a license, but can only use a subset of functionalities. |
| Any PIPEFORCE user is assigned to this role. It allows to login to the system. |
| Any employee of our customers which should see a subset of apps in the portal need to be assigned this role. |
| Any user who wants to be able to develop custom apps need to be assigned to this role. |
| Special role for our support team. |
| Any user assigned to this role has the permission to manage users and settings, but cannot create apps. |
| A system user is assigned this role. |
Why are there default composite roles and default groups?
Since PIPEFORCE is a microservice system, it hosts many different services. Some of them require groups and some can work with roles. Furthermore, there is also a conceptional difference: Groups can be created and managed by admins, roles cannot. They can only be assigned and revoked by admins.
Command Permissions (CAN_CMD_)
For any command in PIPEFORCE, there is a corresponding role (or permission) which allows the user assigned to this role to execute this command. The role name has the format:
CAN_CMD_<command_name>Some examples:
Command Name | Permission / Role Name |
|
|
|
|
|
|
See Role Mappings section for users and groups in IAM for a full list of all available command permissions.
Wildcard command permission (use with maximum care!)
Besides the specific command permission, you can also use the wildcard permissions in order to give a permission to all commands or a specific subset. This should not be used by users, but is reserved for admins and developers.
Examples:
CAN_CMD_%: Grants access to all commandsCAN_CMD_drive.%: Grants access to all drive commands
App Permissions (CAN_APP_)
Note: Depending on the setup of your PIPEFORCE system, these steps usually are done by your global corporate admin and cannot be done by developers or default admins. Please ask your global admin or the PIPEFORCE support team to do these steps for you.
By default, new applications are shown only to users assigned to the role ROLE_DEVELOPER or ROLE_ADMIN.
In order to provide your application also to non-developers, you need to do these manual steps:
Login to IAM.
Create a new role
CAN_APP_<APPNAME>.Assign this new role to all users or groups who should have access to this app.
Note: Make sure to replace <APPNAME> by the real name of your app with all letters upper case. So, let,s assume you have created an app myapp, then you should create a new role CAN_APP_MYAPP.
Also, make sure that users and groups you want to give access to your app are trustworthy. Furthermore, make sure that they also have the permission to access all commands you are using inside your app.
Automate setup of app permissions
Instead of manually creating and assigning the roles of your app, you can automate these steps by providing a setup pipeline using the iam.* commands. To do so, follow these steps:
Create a new pipeline inside the setup folder of your app, for example:
global/app/myapp/setup/create-default-permissionsOpen this pipeline, add this content, and then publish + execute it:
headers:
description: "Creates the default users, groups and permissions of myapp"
onCommandError: "IGNORE"
pipeline:
- iam.run.as:
username: systemuser
# Create the new app role
- iam.role.create:
name: "CAN_APP_MYAPP"
# Assign this role to all employees automatically
- iam.role.add.composites:
roleName: "ROLE_EMPLOYEE"
composites: "CAN_APP_MYAPP"In future, whenever your app is installed on a fresh PIPEFORCE instance, this setup pipeline is executed. So, any required roles and assignments are created.
In the headers section, we set special fields:
description: The description of this pipeline.onCommandError: This defines what should happen if a command in the pipeline fails. In this case, weIGNOREsuch a problem, since it would usually mean that the role already exists or was already assigned.
For more information about the available default headers, see Pipeline Headers Reference .
In the pipeline section, we use these commands:
iam.run.as: This runs the commands as this user.iam.role.create: This creates a new custom role.iam.role.add.composites: This adds an existing role as a child to another role (to make a combination of roles).
For more information about the available iam.* commands, see the commands' dashboard of your instance.
What is a Group?
A group in PIPEFORCE combines a set of users with a set of roles. Groups are typically created and managed by admins. There can be “factory default” groups and also customer specific groups.
Default Groups
There are some default groups in PIPEFORCE. These groups may not be renamed or deleted by admins or developers, otherwise the system will no longer work as expected. These default groups are:
Group name | Description | Requires license |
| Members of this group can create and manage users & groups, but cannot create and develop apps. | Yes |
| Members of this group can create and manage users & groups. They cam also create and develop apps. | Yes |
| Members of this group can login to the system and use it, but they cannot create or manage users, and they cannot create or develop apps. | Yes |
| Member this group can login to the system, but they can see only a very limited set of functionalities. These members are typically managed by the system. | No |
| Members of this group cannot login to the portal, but can use a limited set of features in the system. These members are typically managed by the system. | No |
| Members of this group can see and execute tasks from the workflow tasks' list, and they can get additional information about workflows. | Yes |
| Members of this group can see and execute tasks from the workflow tasks' list. | Yes |
For any app or process, there can be additional groups, depending on the license you are using.
Each group can contain one or more roles which is the core permission entity.
Anonymous User
In case a user is not logged-in, the system handles this automatically as anonymousUser with no roles/permissions and no groups assigned to it. Such a user can only execute a very limited set of public commands.