Example Authorization Configuration
Example Configuration
The following example illustrates how authorization can be configured to support various use cases.
Let's assume ProcessMaker IDP is used by an HR department with two HR managers, each managing a department with two employees.
HR managers can add files and subfolders to the employee folders within their departments.
Employees are only allowed to read their folders and upload files; they cannot create subfolders or update/delete files.
Changes to departments or employee assignments are made by the admin.
The folder structure is as follows:
Department A
Employee name 1
Employee name 2
Department B
Employee name 3
Employee name 4
Roles
Example roles include:
MANAGER_DEPARTMENT_A
MANAGER_DEPARTMENT_B
EMPLOYEE_NAME_1
EMPLOYEE_NAME_2
EMPLOYEE_NAME_3
EMPLOYEE_NAME_4
Note that in the given example, roles mostly correspond to individual users. If this configuration were for an archiving system, it would be more likely that multiple users would have the same access levels and therefore could share the same role.
Create Permission Policies
Create permissions differ from other permissions as they apply to an entity type instead of an entity instance. Due to this difference in scope, it is recommended to keep policies that include the create permission separate from policies with other permissions. For the HR configuration, HR managers can create files and folders, while employees can only create files. The following policies are used:
CREATE_FOLDERS
CREATE_FILES
Both policies have the CREATE permission and no other permissions. The CREATE_FOLDERS policy is assigned to the FOLDER entity in the ENTITY_POLICY table, while the CREATE_FILES policy is assigned to the FILE entity. The CREATE_FOLDERS policy is assigned to both MANAGER roles. The CREATE_FILES policy is assigned to all roles.
Employee Policies
Employees have only one type of permission applicable to their own employee folder and all its subfolders. Different policies need to be created for each employee to distinguish between their folders. The following policies are used:
EMPLOYEE_NAME_1
EMPLOYEE_NAME_2
EMPLOYEE_NAME_3
EMPLOYEE_NAME_4
Employees are able to see their personal folder and upload files to it. Therefore, the READ permission and a foreign key permission for the FK_FILE_PARENT foreign key are assigned to these policies.
Manager Policies
For managers, a distinction can be made between two types of folders: department folders (the dossiers) and employee folders. Additionally, there are separate folders for each department and for each employee. The following policies are used:
MANAGER_DEPARTMENT_A_ROOT
MANAGER_DEPARTMENT_B_ROOT
MANAGER_EMPLOYEE_NAME_1
MANAGER_EMPLOYEE_NAME_2
MANAGER_EMPLOYEE_NAME_3
MANAGER_EMPLOYEE_NAME_4
The root folder only requires the READ permission. Managers are not allowed to change the department name or add new employees, as these privileges are reserved for the admin. The employee policies require the READ, UPDATE, and DELETE permissions.
Please note that the CREATE permission is only applicable to the entity type. To allow the creation of files and folders, foreign key permissions are used. Since managers are allowed to create both files and folders, two foreign key permissions are added with the FK_FOLDER_PARENT and FK_FILE_PARENT foreign keys.
Default Policies
In the given example, no entity-level default policies are used. For files and subfolders, default policies defined by foreign key permissions will overwrite entity-level policies. When creating dossiers, entity-level policies are applicable. However, in this example, there is no overlap between dossier policies as they represent different departments.
Please note that entities created without default policies can only be viewed or edited by admin users. This implies that if a non-admin user creates such an entity, they cannot view it. In the given example, the admin is responsible for creating dossiers.
Both managers and employees are only able to create entities within an employee folder. Within this folder, they will have the MANAGER_EMPLOYEE_NAME_x
and EMPLOYEE_NAME_x
policies. These policies already have foreign key permissions defined. The MANAGER_EMPLOYEE_NAME_x
and EMPLOYEE_NAME_x
policies are both added to these foreign key permissions.
Please note that when an employee uploads a file, this file should also have the MANAGER_EMPLOYEE_NAME_x
policy so that the manager can read, edit, or delete the file. Similarly, when the manager uploads a file, the EMPLOYEE_NAME_x
policy should be assigned so that the employee can read the file.
Last updated