Camunda 8.8 - User Tasks Access Restriction - Tasklist API V2

Camunda 8 Topics
1

Based on this resource: User task access restrictions | Camunda 8 Docs it seems that in Tasklist V2 API, user task access restrictions are not supported - including functionalities such as Candidate Groups and Users.

  1. The intentions of Camunda for future releases regarding Candidate Groups and Users are unclear. Is Tasklist V2 API going to support Candidate Groups or should we completely migrate to using authorization-based access control?
  2. The above resource provides a workaround: For Tasklist V2, use authorization-based access control to manage user permissions and control access to tasks.
    1. Can someone provide more details on how to configure this from the Authorizations tab in Orchestration Identity?
2

Hi @Nikos_M,

Great questions about Tasklist V2 API and user task access restrictions! Let me address both of your points:

1. Future Support for Candidate Groups/Users in Tasklist V2 API

You’re correct that Tasklist V2 API currently does not enforce candidate groups and users restrictions. This is by design - as documented in the user task access restrictions guide:

“This configuration does not affect API users. When retrieving tasks using the APIs, all tasks are returned.”

Current Behavior:

  • Tasklist UI: Automatically enforces candidate users/groups restrictions
  • Tasklist V2 API: Returns all tasks regardless of candidate assignments

Future Intentions: Based on the available documentation, there’s no clear roadmap information about native candidate groups/users support being added to the V2 API. The current design appears intentional to provide flexibility for custom task applications with business-specific authorization rules.

Recommendation: For now, you should implement your own authorization logic when using the V2 API, filtering tasks based on the user’s identity and group memberships extracted from authentication tokens.

2. Authorization-Based Access Control Configuration

Regarding the authorization-based access control workaround, here are the key details:

Finding the Authorizations Tab

Important: The Authorizations tab is only available in the Orchestration Cluster Identity UI, not the Management Identity UI. This is a critical distinction in Camunda 8.8:

  • Management Identity (usually at /identity path): For platform components - NO Authorization tab
  • Orchestration Cluster Identity (usually at root / path): For runtime components - HAS Authorization tab

Configuration Requirements

To use resource authorizations, you need to:

  1. Enable the feature using environment variables in Identity, Operate, and Tasklist

  2. Configure a database for Identity (required for resource authorizations)

  3. Use Keycloak as IdP (resource authorizations only work with Keycloak)

Managing Authorizations

Once configured, you can create authorizations through:

For Groups: Groups tab → Select group → Authorizations tab → Create resource authorization
For Users: Users tab → Select user → Authorizations tab → Create resource authorization

Current Limitations

Resource authorizations currently support:

  • Process permissions: Read, Delete, Update process instance, Delete process instance, Start process instance
  • Decision permissions: Read, Delete

Note: This doesn’t directly solve the candidate groups/users issue for V2 API, as these authorizations work at the process/decision level, not individual task level.

Bottom Line

For Tasklist V2 API with candidate groups/users functionality, you’ll still need to implement custom authorization logic in your application code, as the current authorization system doesn’t provide task-level candidate filtering through the API.

Would you like me to elaborate on any of these points or help you think through the custom authorization implementation approach?

References: