...
| Info |
|---|
Note that you need to have to be member of |
| Table of Contents |
|---|
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:
...
Each group can contain one or more roles which is the core permission entity.
Role and 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 namings are equal. Depending on the usage context it makes sometimes more sense to call it role or permission on the other hand.
...
| Info |
|---|
Roles can also contain other roles, such parent roles are called Composite Roles. You probably never require such type of roles, they are mainly used PIPEFORCE internally only. |
Default Roles
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.
...
| Tip |
|---|
Why are there default composite roles and default groups? Since PIPEFORCE is a microservice system, it hosts many different such 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 not. They can only be assigned and revoked by admins. |
Command Permissions
For any command in PIPEFORCE there is a corresponding role (= permission) which allows the user assigned to this role to execute this command. The role has the format CAN_PIPE_<command_name>. Some examples:
...
| Info |
|---|
Wildcard command permission (use with maximum care!) Examples:
|
App Permissions
| Note |
|---|
Note: Depending on the setup of your PIPEFEORCE 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. |
...
| Note |
|---|
Also make sure that users and groups you want to give access to your app are trustworthy. Furthermore make sure that they have also 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:
...
For more information about the available iam.* commands see the commands dashboard of your instance.
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.
...