Part 039 — Authorization, Identity, and Multi-Tenancy

1. Core mental model

Workflow authorization is not only about who can log in to Camunda.

In production workflow systems, authorization decides who can see, start, operate, repair, migrate, retry, complete, assign, and inspect a business process.

For a CPQ/order-management platform, this is not cosmetic. A workflow may expose:

• quote approval state;
• commercial pricing information;
• customer/order identifiers;
• fallout reason;
• manual intervention notes;
• process variables;
• task forms;
• incident payloads;
• worker failure details;
• operational dashboards;
• audit evidence;
• tenant/customer boundary.

A senior engineer should treat workflow authorization as a first-class architecture concern, not as a UI feature.

The minimum mental model:

identity       = who or what is calling
assignment     = who should work on a task
authorization  = who is allowed to perform an action
tenancy        = which customer/business partition the resource belongs to
audit          = evidence of the action and decision

These concepts overlap, but they are not the same.

A user may be assigned a task but not authorized to see sensitive variables. A worker may be authorized to activate jobs but not to operate incidents. An admin may view incidents but not be allowed to approve a quote. A tenant-aware process may be correctly partitioned in the engine but leak data through logs, search indexes, dashboards, or custom APIs.

2. Identity vs authorization vs assignment

Do not collapse these concepts:

Human task assignment is often mistaken for authorization.

That is dangerous.

A BPMN user task may say candidate group order-ops, but your backend still needs to decide:

• whether the caller belongs to the group;
• whether the caller belongs to the correct tenant;
• whether the caller can see the task payload;
• whether the caller can complete the task action;
• whether the caller can see incident details;
• whether the caller can perform admin operations;
• whether the action must be audited in a separate business audit table.

3. Authorization surfaces in workflow systems

Workflow authorization has more surfaces than a typical CRUD service.

The mistake is to secure only the login page and forget the operational APIs.

4. Camunda 7 authorization model — architecture awareness

Camunda 7 is Java-based and commonly integrated into Java applications as embedded, shared/container-managed, or remote engine deployments.

Key authorization concepts in Camunda 7:

• users;
• groups;
• tenants;
• authorizations;
• resource types;
• permissions;
• identity service;
• REST API security;
• Cockpit/Tasklist/Admin access;
• process engine authorization checks;
• external identity provider integration if configured.

In Camunda 7, the engine can be embedded inside the same JVM as a Java/JAX-RS service. That creates a critical distinction:

Caller --> JAX-RS endpoint --> Java service --> Camunda engine API

If the Java service calls Camunda engine APIs directly, Camunda may not automatically know the original business user unless your application propagates identity correctly.

Senior review question:

Is the Camunda operation executed under the real user identity, a technical service identity, or no meaningful identity at all?

This matters for:

• task query filtering;
• task completion authorization;
• process start authorization;
• tenant restriction;
• audit trail;
• incident repair attribution;
• compliance evidence.

5. Camunda 7 embedded/shared engine risk

Embedded Camunda 7 can be operationally convenient, but authorization can become implicit.

Typical risk pattern:

HTTP request from user
  -> JAX-RS resource validates coarse role
  -> service method calls runtimeService / taskService
  -> engine operation succeeds
  -> no explicit check that user may act on this process/task/tenant

This is not a Camunda problem; it is an integration design problem.

Review rules:

• REST authorization must not be weaker than Camunda authorization.
• Camunda authorization must not be bypassed by direct service calls.
• service accounts must be scoped.
• admin endpoints must be separated from user task endpoints.
• tenant boundaries must be checked before querying or completing tasks.
• process repair endpoints must require stronger permission than normal task completion.

6. Camunda 8 authorization and Identity awareness

Camunda 8 uses a different architecture from Camunda 7.

The process engine is not embedded in the Java service. Java/JAX-RS services interact with a remote orchestration platform through clients/APIs and workers.

Key components to reason about:

• Orchestration Cluster;
• Zeebe;
• Admin;
• Operate;
• Tasklist;
• Orchestration Cluster APIs;
• Identity / access control model;
• users;
• groups;
• roles;
• tenants;
• authorizations;
• clients/service accounts;
• worker credentials;
• API tokens/JWT/OIDC integration;
• management/modeling component access if used.

Important distinction:

Camunda 8 user access control != worker authorization != custom JAX-RS API authorization

A worker credential that can activate jobs is not a human approver. A human user who can complete a task should not automatically have operational incident permissions. A custom backend that queries process status must enforce its own business authorization even when Camunda APIs are protected.

7. Camunda 7 vs Camunda 8 authorization difference

Migration from Camunda 7 to Camunda 8 is not only a worker migration. It is also an authorization migration.

Check:

• how users are represented;
• how groups are mapped;
• how tenants are represented;
• how task permissions change;
• how operational permissions change;
• how service credentials are rotated;
• how custom APIs preserve old authorization semantics.

8. Tenant isolation models

Multi-tenancy can mean several different things.

Do not assume that a tenantId field alone provides end-to-end isolation.

A tenant boundary must be enforced across:

• process definition deployment;
• process instance creation;
• task query;
• task completion;
• variable query;
• incident visibility;
• Operate/Cockpit access;
• custom API query;
• search index;
• logs;
• metrics labels;
• Kafka/RabbitMQ topics;
• PostgreSQL tables;
• Redis cache keys;
• backup/restore;
• support/admin tooling.

9. Process definition permission

Starting a process is a business operation.

For quote/order systems, starting a process may create a long-running business artifact or trigger downstream side effects.

Review questions:

• Who can start this process?
• Can it be started from UI, API, event, scheduler, or worker?
• Is start permission tied to role, tenant, product line, channel, or order type?
• Is there an idempotency key for repeated start attempts?
• Can an external event start a process for a tenant the caller should not access?
• Is process start audited as business action or only technical engine event?
• Can an old process version still be started?
• Can test/demo process definitions be started in production?

Anti-pattern:

Any authenticated internal user can start any process by processDefinitionKey.

Better pattern:

API checks business command permission
  -> validates tenant/customer scope
  -> maps command to allowed process key/version
  -> starts process with business key/correlation ID
  -> stores audit event

10. Process instance permission

A running process instance can expose business state and allow destructive operations.

Actions requiring explicit permission:

• view process instance;
• view variables;
• view active element/task;
• cancel process instance;
• modify token/activity state;
• migrate instance;
• retry failed job;
• resolve incident;
• correlate message;
• manually repair state.

Production rule:

Read access is not repair access. Repair access is not deployment access. Deployment access is not business approval access.

In CPQ/order systems, cancellation or repair may trigger customer-visible effects. Treat these as privileged business operations with audit and approval requirements.

11. Task permission

Task permission is more than candidate group.

A robust task authorization design answers:

• who can see task existence;
• who can see task payload;
• who can claim/unclaim;
• who can complete;
• who can reassign;
• who can delegate;
• who can escalate;
• who can override SLA;
• who can add comment/note;
• who can view previous decision history;
• who can reopen/rework.

Potential model:

candidate group    = expected work queue
assignee           = current owner
business role      = domain-level permission
tenant/customer    = isolation boundary
data sensitivity   = variable/form visibility boundary
operation type     = view/claim/complete/reassign/admin

A task can be visible to a group but still require additional domain authorization for specific actions.

Example:

A support user may view order fallout tasks for tenant A.
Only pricing approvers may approve discount exceptions.
Only supervisors may override SLA or reassign stuck tasks.
Only platform operators may retry technical incidents.

12. Variable visibility permission

Process variables are often the easiest place to leak data.

Variables may contain:

• customer ID;
• account ID;
• quote amount;
• discount;
• contract term;
• order payload;
• pricing exception;
• fallout reason;
• API response;
• error detail;
• external system reference;
• temporary credentials by mistake.

Variable access must be considered separately from process/task access.

Recommended design:

• store only minimal workflow context in variables;
• store sensitive domain data in business tables with existing authorization;
• expose task-specific view DTOs instead of raw variables;
• avoid putting secrets or full external API payloads in variables;
• classify variables by sensitivity;
• redact variables in logs and incidents;
• avoid broad variable search endpoints for normal users.

13. Worker credential model

Workers are machine identities.

They should be scoped like production service accounts, not treated as anonymous background processes.

A worker credential may allow:

• job activation;
• job completion;
• job failure reporting;
• BPMN error throwing;
• variable writing;
• message publishing/correlation;
• external API calls;
• database updates;
• event publishing.

Worker authorization questions:

• Which job types can this worker handle?
• Which environment can it access?
• Which tenant/process scope can it operate on?
• Which secrets can it read?
• Which APIs can it call?
• Which DB tables can it write?
• Which Kafka/RabbitMQ topics can it publish/consume?
• Can it modify variables beyond its task output?
• Are credentials rotated?
• Are credentials unique per worker type or shared globally?

Anti-pattern:

One all-powerful worker credential for every job type in every environment.

Better:

least-privilege credential per worker family / bounded context / environment

14. JAX-RS integration authorization pattern

For Java/JAX-RS services, workflow authorization should usually be enforced before calling Camunda.

Example command path:

POST /quotes/{quoteId}/approval-tasks/{taskId}/complete
  -> authenticate caller
  -> load quote/order/task summary
  -> verify tenant/customer scope
  -> verify role/action permission
  -> verify task belongs to quote/order
  -> verify task is claimable/completable
  -> validate request body
  -> complete task / correlate message
  -> write audit event
  -> return deterministic response

Avoid this:

POST /camunda/tasks/{taskId}/complete
  -> pass through caller request to Camunda

Raw pass-through APIs tend to leak engine internals and bypass domain authorization.

15. PostgreSQL/MyBatis authorization impact

Workflow authorization cannot be separated from database access.

Common data joins:

processInstance.businessKey -> quote.id / order.id
processVariable.quoteId     -> quote.id
userTask.businessKey        -> quote.id / order.id
incident.processInstanceKey -> business entity

If the custom backend uses PostgreSQL/MyBatis to build task views, enforce authorization in query design.

Review points:

• tenant filter must be mandatory;
• task query must join to business entity ownership;
• user role filter must apply before pagination;
• row-level constraints should be represented in SQL, not only post-filtered in Java;
• audit table should capture user/action/entity/task/process IDs;
• service account DB permissions should be least privilege;
• task search indexes must not bypass DB authorization.

Bad pattern:

SELECT * FROM task_view WHERE status = 'OPEN';
-- then filter in Java

Better pattern:

SELECT *
FROM task_view tv
JOIN user_tenant_scope uts ON uts.tenant_id = tv.tenant_id
WHERE tv.status = 'OPEN'
  AND uts.user_id = :currentUserId;

16. Kafka/RabbitMQ authorization impact

Workflow events and messages can bypass normal API authorization if not designed carefully.

Examples:

• Kafka event starts process for wrong tenant.
• RabbitMQ command completes a task without user context.
• External callback correlates to process instance using guessable key.
• Replay restarts or re-correlates process messages.
• DLQ replay runs under operator identity without business authorization.

Message authorization questions:

• Is the producer trusted?
• Is the event signed or source-validated?
• Is tenant/customer scope part of the message?
• Is correlation key guessable?
• Is replay allowed to trigger side effects?
• Is operator DLQ replay audited?
• Is user identity preserved when a human action becomes an event?
• Can one tenant publish a message affecting another tenant?

17. Redis authorization impact

Redis is often used for cache, lock, rate limiting, or worker coordination. It can leak or corrupt authorization boundaries if key design is weak.

Review points:

• tenant must be part of cache key where relevant;
• process/task status cache must not be shared across tenants;
• authorization decision cache needs short TTL and invalidation plan;
• distributed locks must include business scope;
• task visibility cache must not outlive permission changes;
• feature flags/kill switches must be restricted to privileged operators;
• Redis dumps/backups may contain sensitive values.

Never treat cached authorization as final truth without a clear invalidation story.

18. Kubernetes/cloud/on-prem implications

Authorization is also infrastructure.

In Kubernetes/cloud/on-prem/hybrid environments, verify:

• worker service account mapping;
• Kubernetes ServiceAccount/IAM/managed identity binding;
• secret mount scope;
• network policy between worker and Camunda endpoint;
• ingress authentication for Tasklist/Operate/Cockpit;
• admin UI exposure;
• private endpoint / firewall rules;
• mTLS/TLS termination;
• cross-cluster tenant boundary;
• on-prem customer support access;
• break-glass account process;
• audit of operational actions.

Common production failure:

Application authorization is correct, but Operate/Cockpit/Tasklist/admin endpoint is reachable by too many people.

19. Failure modes

20. Debugging authorization incidents

When debugging authorization issue, avoid jumping straight to UI symptoms.

Use this chain:

1. Who is the caller identity?
2. What authentication mechanism was used?
3. Which role/group/tenant mapping applied?
4. Which resource was accessed?
5. Which operation was attempted?
6. Was authorization checked in Camunda, custom API, DB query, or all of them?
7. Was task assignment confused with permission?
8. Was data retrieved from cache/search index instead of authoritative DB/API?
9. Was action performed by human user or service account?
10. Is there audit evidence?

For task visibility bugs, check:

• task candidate group;
• assignee;
• tenant ID;
• process definition key;
• process instance business key;
• custom task view query;
• Tasklist/Camunda authorization config;
• frontend filter;
• cache key;
• search index refresh;
• identity mapping sync.

For worker authorization bugs, check:

• worker credential;
• job type;
• environment;
• tenant/process scope;
• secret access;
• network policy;
• logs/traces for activation/completion;
• whether duplicate workers exist.

21. Production review checklist

Use this checklist for PRs, ADRs, and architecture review.

Identity

• Is the caller identity explicit?
• Is user identity propagated from JAX-RS/API to workflow action where required?
• Are service accounts separate from human users?
• Are worker credentials unique and scoped?
• Is SSO/OIDC/JWT/mTLS integration understood?

Authorization

• Are process start permissions explicit?
• Are task view/claim/complete/reassign permissions explicit?
• Are incident retry/resolve permissions stronger than normal task permissions?
• Are variable read/write permissions considered?
• Are admin operations restricted?
• Are custom APIs enforcing domain authorization before calling Camunda?

Assignment

• Are candidate users/groups meaningful?
• Is assignment separated from authorization?
• Is stale assignment handled?
• Is reassignment audited?
• Are SLA/escalation permissions explicit?

Tenancy

• Is tenant ID propagated consistently?
• Are process definitions tenant-scoped if needed?
• Are process instances tenant-scoped?
• Are tasks filtered by tenant?
• Are variables/incidents/dashboard/search indexes tenant-safe?
• Are Kafka/RabbitMQ/Redis keys tenant-safe?

Audit

• Is business action audit captured?
• Is technical Camunda audit sufficient or do we need domain audit?
• Are repair operations audited?
• Are break-glass actions audited?
• Can audit evidence answer who/what/when/why?

22. Internal verification checklist

Verify in the actual codebase, deployment, and team practice:

• Which Camunda version is used: Camunda 7, Camunda 8 SaaS, Camunda 8 self-managed, both, or none.
• Whether Camunda 7 authorization checks are enabled and used.
• Whether Camunda 7 engine is embedded, shared/container-managed, or remote.
• Whether Camunda 8 Identity/authorization/tenancy is enabled and how it is configured.
• How users, groups, roles, and tenants are sourced from enterprise identity provider.
• How custom JAX-RS APIs enforce workflow authorization.
• Whether task assignment is incorrectly treated as task authorization.
• Whether Tasklist/Cockpit/Operate/Admin are exposed and to whom.
• Whether process variables are visible to normal users/operators.
• Whether worker credentials are scoped by job type/environment/tenant.
• Whether service accounts are rotated and audited.
• Whether incident retry/resolve requires privileged access.
• Whether process migration/cancellation/modification is restricted.
• Whether tenant filters exist in PostgreSQL/MyBatis task/process queries.
• Whether Kafka/RabbitMQ events include tenant and correlation metadata.
• Whether Redis cache/lock keys include tenant/business scope where required.
• Whether operational dashboards leak cross-tenant data.
• Whether internal support/break-glass access has audit and approval.
• Whether authorization changes are tested in CI.
• Whether there is an ADR for tenancy and authorization model.

23. Senior engineer heuristics

Use these rules when reviewing workflow authorization:

1. No raw engine pass-through API for normal users. Wrap Camunda operations behind domain-aware APIs.
2. Assignment is not authorization. Candidate group answers who should work, not who is allowed.
3. Service account is not admin by default. Scope machine credentials.
4. Tenant ID must travel with the process. API, DB, variable, event, cache, and dashboard must agree.
5. Repair is more privileged than normal execution. Retry, cancel, migrate, and modify need stronger controls.
6. Variable access is data access. Treat variables like sensitive records, not harmless metadata.
7. Audit business decisions outside engine history when needed. Engine history may not answer domain audit questions.
8. Camunda 7 and Camunda 8 authorization differ. Do not copy assumptions during migration.
9. Custom UI means custom responsibility. If you bypass Tasklist, you own task security semantics.
10. Operational tools are production attack surfaces. Secure Operate/Cockpit/Tasklist/Admin as real admin systems.

24. Official documentation anchors

Use these as starting points, then verify against the exact internal version:

• Camunda 8 Orchestration Cluster authorization.
• Camunda 8 access control overview.
• Camunda 8 user task authorization.
• Camunda 8 Administration API authentication.
• Camunda 8 Identity / access management for self-managed deployments.
• Camunda 7 securing guide.
• Camunda 7 identity and authorization APIs.

Do not assume the latest documentation exactly matches the deployed version in a production customer environment.