Permissions and Roles

General permissions API

For all the roles and permissions endpoints, documentation can be found in the API’s swagger page.

To understand how this “Roles, Objects, and Permissions” system is based, we need to define the schema it’s built upon.

RBAC.

What is RBAC?.

Role-Based Access Control (RBAC) is an approach to restrict access to the system to authorized users and to implement Mandatory Access Control (MAC) or Discretionary Access Control (DAC), where roles and privileges are worked with.

Based on this model, we can say that we have 4 important points in the Dynamic app system: Role, Objects, Actions, and Permissions.

Roles.

User’s role within the application domain.

For managing roles, we have all (GET, POST, PUT, DELETE) the /api/v1/roles endpoints.

For managing objects and actions stored for roles: GET /api/v1/roles/objects and GET /api/v1/roles/actions respectively.

There are also endpoints for:

• Managing (GET, PUT, DELETE) users and their roles in /api/v1/roles/{roleId}/users/ and /api/v1/roles/{roleId}/users/{userId}

• Managing (GET, PUT, DELETE) domains and their roles in /api/v1/roles/{roleId}/domains/ and /api/v1/roles/{roleId}/domains/{domainId}

Objects.

Entities and definitions within the application.

For managing objects, we have everything explained in the Entity section.

Actions.

Allowed actions within the application, previously predefined with the possibility of being created in the future.

In this moment, we don’t have a route to managing actions.

Permissions.

Actions allowed for roles regarding objects.

The relationship of roles with actions is seen in the role_has_permission table. This table takes the IDs from the role and permission tables, and on this table, it’s defined which roles have which permissions. This table should be used to visualize and enable modules regarding the enabled actions.

For managing permission, we have all (GET, POST, PUT, DELETE) the /api/v1/permissions and /api/v1/studio endpoints.

For managing specific role permissions, the /api/v1/roles/{roleId}/permissions parameter can be used.