Authorization
Authorization in ProcessMaker IDP ensures secure and controlled access to documents and resources. It is based on role-based access control (RBAC), where permissions are managed through roles and policies rather than individual users. Here’s what users can expect:
Role-Based Access Control
Permissions are determined by roles, which are assigned by administrators. Roles define what actions users can perform, such as reading, creating, or modifying documents.
Permissions and Policies
Policies link roles to specific permissions and entities, determining the actions users can take. For instance, a policy might allow users to read a document but not edit it.
Policies ensure users have access to necessary resources without compromising security.
User Experience
Depending on their role, users will see different options and actions available in the document management interface.
For example, a manager might have the ability to create and manage folders, while an employee might only have access to upload and view documents within their assigned folders.
Data Model
ProcessMaker IDP is based on role-based access control. Permissions are therefore managed through roles and policies rather than on a user-based level. Users and roles are managed in Keycloak, where policies and permissions are managed in the datastore.
Enabling/Disabling Authorization
By default, authorization is not enabled. It can be enabled at the environment and entity type levels. Authorization is automatically enabled on an environment once the DOCULAYER_ADMIN role is created. This role can perform all actions even if no policies are defined.
Authorization Logic
The system checks several conditions to determine if a user can perform a requested action on non-system entities. The following questions show the general logic of this operation:
Is the
DOCULAYER_ADMINrole present in ProcessMaker IDP?Is the
ENABLE_AUTHORIZATIONvalue true for the entity the user wants to act on?Does the user have one or more policies assigned with a permission that corresponds to the action they want to perform?
Does the entity have at least one policy assigned that matches the relevant user policies?
Create Flow
Create Permission
Authorization for a create request differs from other types of requests. Since it is not possible to check permissions on an entity that has not yet been created, the create permission applies at the entity type level rather than the entity instance level, as with read, modify, and other permissions. Therefore, the create permission should only be used in relation to an entity type
It is highly recommended to separate policies that contain the create permission to prevent confusion.
The create permission determines whether the current user can create an entity of a specific type.
Example:
For a file, this translates to: Can the user upload a file to the system? This does not relate to any specific folder at this point.
Foreign Key Permission
In addition to the create permission, foreign key permissions might also apply to a create request. Foreign key permissions are relevant when the created entity contains one or more references. The permissions of the referenced items are considered.
Foreign key permissions provide the functionality to limit the folders in which a user can upload a file.
Foreign key permissions determine whether the current user can create an entity of type X that contains a reference to item Y.
For example, for a file, this means: Can the user create a file X that contains a reference to folder Y?
User Permissions
User permissions determine who is allowed to perform specific actions within ProcessMaker IDP. These permissions are set to control access and define the capabilities of each user, ensuring that only authorized individuals can perform certain tasks, such as creating, reading, modifying, or deleting documents and folders. This structure helps maintain security and order within the system by clearly defining user roles and their corresponding permissions.
Entity Permissions
When authorization is enabled for an entity type, a corresponding _POLICY entity is created to store the authorization policies. When authorization is disabled, the _POLICY entity is not removed automatically to prevent data loss. It can still be removed from the admin panel.
Policy Inheritance
For any user to perform actions on an entity, the entity must have policies assigned. Since manually adding these policies can be time consuming, they can be inherited from a list of default policies. Default policies can be defined at the entity type level or based on a relation.
Entity-Level Default Policies:
Policy Propagation
Policy propagation allows the inheritance of parent-level permissions to child entities. This allows users to control how permissions are inherited within their entity relationships, ensuring that permissions are appropriately managed according to their organizational requirements.
Propagate Permissions
The parent-child relationship is determined by the foreign keys of an entity. When creating the foreign keys for an entity type, users must specify which foreign key relationship represents the parent-child relation by selecting an attribute. This is necessary because an entity may have multiple foreign keys.
When permissions in a parent-child relationship are modified, these changes can be automatically propagated to the child entities.
Policy propagation occurs only if the parent’s propagate flag is set to true and the child's inhibit propagate flag is set to false.
Inhibit Propagate Permissions
The Inhibit Propagate feature prevents the inheritance of parent-level permissions to child entities. When permissions are propagated from a parent to a child, setting the child’s inhibit propagate flag to true will disable the propagation for that specific parent-child relationship.
User Interface
User Interface support for authorization is not part of the current release. No default routes are available for any of the authorization entities however, roles, policies, and permissions can be created through the admin panel. If authorization is configured correctly, policies are inherited during the creation of entities.
Last updated