# Roles

## Access Control

The ROCKITPLAY API follows the CRUDX (Create, Read, Update, Delete, Execute) approach. Every endpoint can access a resource such as *Apps*, *Backend Users*, *Bundles*, *Consumption*, *Dependencies*, *Deployments*, *Keys*, *Roles*, *Sources*, *Subscriptions*, *Tasks*, or *Trainings*. The request method specifies how the endpoint accesses the corresponding resource. Typically, that is

* **C**reate:
  `POST /be/v1/*` 
* **R**ead:
  `GET /be/v1/*`
* **U**pdate:
  `PATCH /be/v1/*`
* **D**elete:
  `DELETE /be/v1/*`
* e**X**ecute:
  `POST /be/v1/trigger`

ROCKITPLAY allows to define *Roles* which specify these CRUDX permissions for each individual resource. By associating *Users* with one or many *Roles* the resource access can be controlled for individually.

### Bit masks

The access is defined as bitmask with the following values:

| e**X**ecute | **D**elete | **U**pdate  | **R**ead | **C**reate |
| ----------- | ---------- | ----------- | -------- | ---------- |
|          16 |          8 |           4 |        2 |          1 |

**Example**: To grant `Read` and `Update` permissions define a value of `6 = 4 + 2`.

The following table defines the maximum supported permission values for each resource:

| Resource Id     | CRUDX                                 | Max. Value |
| --------------- | ------------------------------------- | ---------- |
| `apps`          | create, read, update, delete          | 15 |
| `bundles`       | create, read, update, delete          | 15 |
| `consumption`   | read                                  |  2 |
| `dependencies`  | create, read, update, delete          | 15 |
| `deployments`   | create, read, update, delete          | 15 |
| `keys`          | create, read, update, delete          | 15 |
| `roles`         | create, read, update, delete          | 15 |
| `sources`       | create, read, update, delete          | 15 |
| `subscriptions` | create, read, update, delete          | 15 |
| `tasks`         | create, read, update, delete, execute | 31 |
| `trainings`     | read, update                          |  6 |
| `users`         | create, read, update, delete          | 15 |

Each ROCKITPLAY Organization will always have an Administrators *Role* with the above mentioned maximum permission values.

### Example Roles

Depending on the workflow and policies the following *Roles* may be useful:

* Account Admins:
  Grant full access to manage ROCKITPLAY Roles and backend users.
* CI Pipeline Services:
  Allow CI machine users full access to *Apps* only.
* Managers:
  Grant broad access to ROCKITPLAY training cycle except for
  configuring external services such as CDN origins or subscriptions
  (web hooks, Slack).
* System Engineers:
  Grant only access to CDN origins and subscriptions (web hooks, Slack).

and when supporting ROCKIT StreamInstaller:

* Access Control:
  Allow creation of ROCKIT StreamInstaller bundles and control training.
* Testers:
  Grant access to ROCKIT StreamInstaller bundles.

These example *Roles* would be configured with the following permission values:

| Role | apps | beUsers | bundles | consumption | dependencies | deployments | keys | roles | sources | subscriptions | tasks | trainings |
| --- | --- |--- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Access Control | 0 | 0 | 2 | 0 | 0 | 0 | 15 | 0 | 0 | 0 | 0 | 2 |
| Account Admins | 0 | 15 | 0 | 0 | 0 | 0 | 0 | 15 | 0 | 0 | 0 | 0 |
| CI Pipeline Services | 15 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Managers | 15 | 0 | 31 | 0 | 15 | 2 | 15 | 0 | 2 | 0 | 6 | 6 |
| System Engineers | 0 | 0 | 0 | 0 | 0 | 15 | 0 | 0 | 15 | 15 | 0 | 0 |
| Testers | 0 | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |