Authorizations in Orchestration Cluster
Camunda 8's Orchestration Cluster provides a fine-grained authorization system for controlling access to applications and APIs. This system applies to:
- Zeebe
- Operate
- Tasklist
- Orchestration Cluster APIs (e.g., V2 API)
Authorization applies only to these orchestration components. It does not apply to other Camunda services, such as Web Modeler or Optimize.
Core concepts
Authorization model
- Based on the principle of least privilege
- Can be enabled or disabled in both SaaS and Self-Managed environments
- When disabled: all users and clients have full access
- When enabled: no access is granted by default; explicit authorization is required
- No concept of deny rules—absence of permission means no access
- Enforced across both web applications and API requests
Key components
-
Authorizations
- Assign permissions to Identities for specific resources
- Examples:
- User
jonny
is authorized to create new users - Group
marketing
is authorized to delete the groupsales
- User
-
Owners
- Types include users, groups, roles, and mapping rules
- Authorizations can be assigned to any type of owner
-
Permissions
- Define allowed interactions with resources
- Are specific to each resource type
-
Resources
- Entities users interact with
- Each resource has its own set of permissions
Configuration
SaaS configuration
In Camunda 8 SaaS, authorizations can be enabled or disabled per cluster. This setting can be changed by:
- Organization admins
- Organization owners
Self-Managed configuration
In Self-Managed deployments, enable the authorization system using:
- application.yaml
- Environment variables
- Helm values
camunda.security.authorizations.enabled: true
CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED=true
global.security.authorizations.enabled=true
Resources and permissions
Available resources
The following table lists all resources that support authorization in Camunda 8 Orchestration Cluster, along with the available permissions per resource. This applies to Camunda 8 Orchestration Cluster (Zeebe, Operate, Tasklist, Orchestration Cluster APIs).
Resource type | Resource key example | Resource key type | Supported permissions |
---|---|---|---|
Authorization | * | All authorizations | CREATE , READ , UPDATE , DELETE |
Batch | * | All batches | CREATE , CREATE_BATCH_OPERATION_CANCEL_PROCESS_INSTANCE , CREATE_BATCH_OPERATION_DELETE_PROCESS_INSTANCE , CREATE_BATCH_OPERATION_MIGRATE_PROCESS_INSTANCE , CREATE_BATCH_OPERATION_MODIFY_PROCESS_INSTANCE , CREATE_BATCH_OPERATION_RESOLVE_INCIDENT , CREATE_BATCH_OPERATION_DELETE_DECISION_INSTANCE , CREATE_BATCH_OPERATION_DELETE_DECISION_DEFINITION , CREATE_BATCH_OPERATION_DELETE_PROCESS_DEFINITION , READ , UPDATE |
Component | * , operate , tasklist , identity | All components, component name | ACCESS |
Decision Definition | * , order_decision | All decisions / Decision ID | CREATE_DECISION_INSTANCE , READ_DECISION_DEFINITION , READ_DECISION_INSTANCE , DELETE_DECISION_INSTANCE |
Decision Requirements Definition | * , order_decision | All DRDs / DRD ID | READ |
Group | * , accounting | All groups / Group ID | CREATE , READ , UPDATE , DELETE |
Mapping Rule | * , my_mapping | All mappings / Mapping ID | CREATE , READ , UPDATE , DELETE |
Message | * | All messages | CREATE , READ |
Process Definition | * , order_process | All processes / BPMN Process ID | CREATE_PROCESS_INSTANCE , READ_PROCESS_DEFINITION , READ_PROCESS_INSTANCE , READ_USER_TASK , UPDATE_PROCESS_INSTANCE , UPDATE_USER_TASK |
Resource | * , my_form , order_process | All resources / Form ID / Process ID | CREATE , DELETE_DRD , DELETE_FORM , DELETE_PROCESS , DELETE_RESOURCE |
Role | * , myrole | All roles / Role ID | CREATE , READ , UPDATE , DELETE |
System | * | All system operations | READ , UPDATE |
Tenant | * , tenantA | All tenants / Tenant ID | CREATE , READ , UPDATE , DELETE |
User | * , felix.mueller | All users / Username | CREATE , READ , UPDATE , DELETE |
Default roles
Camunda provides predefined roles to simplify access management:
Role ID | Purpose | Typical authorizations |
---|---|---|
admin | Full control over all Orchestration Cluster resources and applications. | All permissions for all resources: READ , CREATE , UPDATE , DELETE , including ACCESS to all applications. |
readonly-admin | Audit-focused users who need read-only access across the Orchestration Cluster. | READ for all resources, including READ_PROCESS_DEFINITION , READ_PROCESS_INSTANCE , READ_USER_TASK , etc. |
connectors | Technical role for executing connector calls. | READ_PROCESS_DEFINITION on Process Definition (* ), UPDATE_PROCESS_INSTANCE on Process Definition (* ), CREATE on Message (* ) |
rpa | Role for RPA workers. | READ on Resource (* ), UPDATE_PROCESS_INSTANCE on Process Definition (* ) |
Role assignment in SaaS
- admin: Automatically assigned to Organization Owner and Admin
- connectors: Automatically assigned to Connectors Runtime in Cluster deployment
- readonly-admin: Automatically assigned to Camunda Support Agents for support cases
Common use cases
Application access
Users need specific application permissions to access Orchestration Cluster components:
- UI access: Resource type
application
and Resource Key is one of the components Operate, Tasklist, Identity- Example:
operate
for Operate access - Example:
tasklist
for Tasklist access
- Example:
- Without these permissions, users cannot log in to the components
Resource access
Within applications, users need additional permissions for specific resources, e.g.:
- Process related: Resource type
processDefinition
READ_PROCESS_DEFINITION
to view process modelsCREATE_PROCESS_INSTANCE
to start new processesUPDATE_PROCESS_INSTANCE
to modify running instances
- Decision related: Resource type
decisionDefinition
READ_DECISION_DEFINITION
to view DMN modelsCREATE_DECISION_INSTANCE
to execute decisions
API access
When implementing your own integrations (e.g., using a Camunda client), you should consider the following:
- Job workers: Resource type
processDefinition
UPDATE_PROCESS_INSTANCE
to complete jobs for the specific process definitions