/
Users, Groups, Roles and Permissions

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

ROLE_GUEST

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.

ROLE_USER

Any PIPEFORCE user is assigned to this role. It allows to login to the system.

ROLE_EMPLOYEE

Any employee of our customers which should see a subset of apps in the portal need to be assigned this role.

ROLE_DEVELOPER

Any user who wants to be able to develop custom apps need to be assigned to this role.

ROLE_SUPPORT

Special role for our support team.

ROLE_ADMIN

Any user assigned to this role has the permission to manage users and settings, but cannot create apps.

ROLE_SYSTEM

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

drive.read

CAN_CMD_drive.read

drive.save

CAN_CMD_drive.save

property.put

CAN_CMD_property.put

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 commands

  • CAN_CMD_drive.%: Grants access to all drive commands

App Permissions (CAN_APP_)