I have Camunda 8.8 locally setup, with local keycloak as OIDC (external IdP). I am trying to figure out how are Candidate Groups working in Tasklist related to the OIDC authentication of users.
My end goal is that users of a specific group can only see User Tasks that are assigned to their candidate group. This was effortlessly done in Camunda 7. How can I do this in Camunda 8 with my above infrastructure setup exactly?
What does this Candidate Group string on User Tasks refer to? Does it correspond to the groups claim of Keycloak OIDC?
Is it supposed to get mapped somehow from the IdP to Identity via rules?
Can I use Roles instead of Groups for Candidate Groups?
I am unable to create groups from the Orchestration Identity:
The above seems like a very basic use case. I simply want to have an external IdP, and particular groups of users to have access to particular User Tasks. I was only able to find this: User tasks | Camunda 8 Docs which is kind of related, but does not remotely analyze the use case.
Great questions about Candidate Groups in Camunda 8.8 with OIDC! Let me break this down for you:
1. What does the Candidate Group string refer to?
The Candidate Group string in User Tasks is essentially metadata that specifies which groups of users can be assigned to that task. It’s just a string identifier - Camunda doesn’t validate what it represents, it’s purely metadata.
Regarding Keycloak’s groups claim: Yes, it can correspond to the groups claim from your Keycloak OIDC token, but this requires proper configuration:
You can configure the groups claim in your Camunda 8 setup using the orchestration.security.authentication.oidc.groupsClaim parameter (defaults to groups)
The candidate group strings in your BPMN model should match the group identifiers that come from your Keycloak groups claim
2. Mapping from IdP to Identity via Rules
Yes, this is handled through Mapping Rules in Camunda Identity. Here’s how it works:
Mapping rules allow you to dynamically assign Identity entities (roles, groups, tenants) to users based on claims in JWT tokens from your external IdP
You can use the Contains operator for array-based claims (like a list of groups from Keycloak)
You can use the Equals operator for string-based claims
These rules automatically assign users to specific roles/groups based on their authentication token claim values
How it all connects:
Keycloak issues OIDC tokens with a groups claim containing the user’s groups
Identity uses mapping rules to map these external groups to internal Camunda groups/roles
Tasklist uses the candidate group strings to determine task visibility based on the user’s assigned groups
When user task access restrictions are enabled (default), only users belonging to the specified candidate groups can see and work on those tasks
Important Notes:
The candidate group strings are case-sensitive and must match exactly with your Identity group names
You need to manually enter the exact group identifiers in the Modeler (no autocomplete for external IdP groups currently)
Groups must be properly created in Identity and mapped via rules for the access restrictions to work
This auto-generated answer is unclear, and possibly outdated with regard to Camunda version 8.8.
You mention: “map these external groups to internal Camunda groups/roles”
How can I map it to Camunda groups? As I stated in my initial question, I am unable to configure groups from the Orchestration Identity UI. It only shows Mapping Rules, Roles, Tenants, Authorizations.
You’re absolutely right, and I apologize for the confusion in my previous response! Let me clarify this for Camunda 8.8 specifically.
Groups Management in Camunda 8.8 Orchestration Cluster Identity
In Camunda 8.8, there was a significant architectural change where Identity was split into two distinct scopes:
Orchestration Cluster Identity - for runtime components (Zeebe, Operate, Tasklist)
Management Identity - for platform components (Console, Web Modeler, Optimize)
Creating Groups in the Orchestration Identity UI
You can create groups directly in the Orchestration Cluster Identity UI. Here’s how:
Navigate to the Groups tab in the Identity interface
Click the Create group button located on the top right of the table
Enter the group name and click Create group
If you’re not seeing the Groups tab, you might be looking at the Management Identity instead of the Orchestration Cluster Identity.
Regarding the Authorization Tab
If you’re missing the Authorization tab in your Identity UI, you may need to enable resource permissions by adding the RESOURCE_PERMISSIONS_ENABLED environment variable set to "true" in your Identity configuration.
How Candidate Groups Work with OIDC
To answer your original questions more accurately for 8.8:
Candidate Group strings are just metadata identifiers that should match the group names you create in the Orchestration Identity UI
Mapping Rules can map external OIDC claims (like Keycloak’s groups claim) to assign users to these Identity groups automatically
The candidate groups in your BPMN tasks should reference the exact group names as they appear in your Orchestration Identity
Workflow:
Create groups in Orchestration Identity UI (Groups tab)
Use Mapping Rules to automatically assign users from Keycloak to these groups based on OIDC claims
Reference these group names as candidate groups in your BPMN user tasks
Tasklist will enforce access restrictions based on group membership
Could you check if you’re accessing the correct Identity instance (Orchestration vs Management) and whether you have the Groups tab available? If you’re still not seeing it, there might be a configuration issue we need to address.
In Camunda 7, assignees and candidates automatically received task-level permissions, making task work straightforward. In Camunda 8, users must hold UPDATE_USER_TASK on the process definition resource, which is impractical compared to C7. I submitted an idea through Camunda roadmap (http://roadmap.camunda.com) portal asking for reintroducing automatic task-level authorizations so assignees and candidates can view and complete tasks without extra configuration. I hope the Camunda team will take this into consideration, as having a mechanism similar to the one in C7 for automatically handling user task related authorizations is essential.
The UPDATE_USER_TASK authorization you are mentioning, is in the Process Definition level, correct? So this will make a user be able to see all user tasks of a Process Definition. My question was how can I make users see only tasks that are candidate to the user’s group. And in general, how this mechamism works in Camunda 8.8 with external identity. Seems like a very basic feature.
To summarize, group mapping is available; however, what is missing are task resource authorizations and a mechanism similar to the one in C7 for automatically handling user task related authorizations
So basically Tasklist is literally unusable for enterprise business in the current state of Camunda 8. We are not able to show user tasks to specific users based on their groups/roles. Each user will see tasks of all users.
It is definitely strange, and provides a very bad impression that this functionality was totally covered in Camunda 7, and in Camunda 8 it is simply not supported, after 4 years of development.
Regarding the group mappings functionality, how exactly is it available? As I stated in my initial comment, once I wired an external identity provider, there was no “Groups” tab in Orchestration Identity UI.
Currently, you can’t directly query tasks from the new Camunda API using a user access token and expect it to return only the tasks where the user is set as an assignee, candidate, or a member of a candidate group.
The current workaround is to introduce an additional backend layer that calls the new Camunda API using client credentials with higher permissions. This layer can then query tasks assigned to the user, the user is set as candidate for, or tasks belonging to candidate groups the authenticated user is a member of.
Currently, you can’t directly query tasks from the new Camunda API using a user access token and expect it to return only the tasks where the user is set as an assignee, candidate, or a member of a candidate group.
My use case is not to query user tasks via tha Camunda API. My use case is that in Tasklist UI, I want users that belong to a group (let’s say GroupA), to only see tasks of their group (tasks that have Candidate Group = GroupA).
Currently, users of group GroupA can see tasks of all groups, which is a problematic behaviour in the Tasklist UI.
However, is Camunda planning to support this with Tasklist V2? It seems that in Camunda 8.10, Tasklist V1 will get deprecated, so I am wondering whether this functionality is supported in the future - starting to have trust issues
