Users, Groups, Roles and Permissions
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