camunda 8.8 how to use identity management to grant access to resources like a teams' models, instances, dashboard etc

Camunda 8 Topics Discussion & Questions
1

Hi there,

i have a question regarding the recently introduced identity management (using Web Camunda 8.8+gen10).

I work with students and do with them a round trip through the bpm life cycle: in small teams they model processes, deploy, run and analyze them. Nowadays within the web modeler they can only see their team’s process models (which is fine), but as soon as the models are deployed they can see in Operate also the models of the other teams and the other dashboards (Optimize) too.

My first question is if (i hope) and how i can use the identity management to grant a student team access only to their own process instances / models / dashboards / collections in Operate and Optimize? I granted them the predefined role developer which grants them access to all components, but I would like to improve that.

Second question: if / how can I grant the students the right to resume the cluster (for education purposes I have a trial cluster which falls asleep after inactivity)?. The predefined role doesn’t include this permission. They should be able to resume it by themselves, but nothing else (e.g. delete it).

Thanks in advance for your answers

Mariele

2

Hi Mariele,

Great questions about using Camunda 8.8’s identity management for educational purposes! Let me address both of your questions:

Question 1: Restricting Access to Team-Specific Resources

Camunda 8.8 uses two different identity systems, which is key to understanding how to set up your access controls:

For Operate (Process Models & Instances)

You can achieve team-based access control using Orchestration Cluster Identity with fine-grained authorizations:

  • Orchestration Cluster Identity controls access to Zeebe, Operate, Tasklist, and cluster APIs
  • You can create resource-level authorizations that grant specific permissions on:
    • Process definitions (models)
    • Process instances
    • Batch operations
    • Components (Operate, Tasklist access)

How to implement this:

  1. Create groups for each student team in Orchestration Cluster Identity
  2. Define authorizations that grant each group:
    • READ permission on specific PROCESS_DEFINITION resources (their team’s models)
    • READ permission on PROCESS_INSTANCE resources for those definitions
    • ACCESS permission to the Operate component
  3. Assign students to their respective team groups

This will ensure each team only sees their own process models and instances in Operate.

For Optimize (Dashboards)

Unfortunately, Optimize access is more coarse-grained:

  • Optimize is controlled by Management Identity with broad permissions
  • The current system only allows granting or denying Optimize access entirely per user/group
  • Fine-grained per-dashboard or per-process access within Optimize is not documented in the current system

So you can control who has Optimize access, but not restrict them to specific dashboards or processes within Optimize.

Question 2: Cluster Resume Permissions

For trial cluster management, the permission model is currently organization-level:

  • Organization Owner and Admin roles have broad rights over cluster lifecycle operations (including resume)
  • The documentation doesn’t describe fine-grained permissions like “resume but not delete”
  • Trial clusters auto-pause after inactivity and can be resumed from the Console

Current limitation: There’s no documented way to grant students only cluster resume permissions without broader administrative rights.

Recommendations

  1. For team-based Operate access: Use Orchestration Cluster Identity authorizations - this will work well for your use case
  2. For Optimize: Consider whether you need it for students, or if you can manage with broader access
  3. For cluster resume: You might need to handle this at the organization level, or consider having a teaching assistant with Admin rights manage cluster resumption

Next Steps

I’d recommend:

  1. Setting up the Orchestration Cluster Identity authorizations for Operate access first
  2. Testing with a small group to ensure it works as expected
  3. For the cluster resume limitation, you might want to submit a feature request for more granular cluster management permissions

Would you like me to provide more specific guidance on setting up the Orchestration Cluster Identity authorizations, or do you have questions about any of these approaches?

References: