Value Proposition Statement
Reduce risk and increase efficiency by standardizing on a single identity and access stack that runs independently in orchestration clusters and Camunda’s new management surface, Camunda Hub. This common stack provides a consistent authorization model reducing confusion and lowering compliance and operational overhead. Deploying in a distributed way improves reliability and reduces blast radius during outages or failures.
User Problem
Today customers must manage two separate identity stacks, one governing access to orchestration clusters and the other governing access to management surfaces such as Web Modeler, Optimize and Console. Because these stacks differ in behaviour and capabilities, a configuration can work in one environment, but fail or behave differently in the other. This split experience increases confusion and operational overhead leading to avoidable troubleshooting cycles and support tickets delaying deployments and upgrades.
Release Notes
Camunda Self-Managed now uses a single unified identity stack across the platform, replacing the Management Identity stack with the stack used in orchestration clusters. This change removes the split identity experience and establishes a single long-term foundation for how authentication and authorization are handled across Camunda components. The result is a clearer, more consistent access model that reduces risk, confusion, and compliance overhead for organizations that want to operate one identity system.
To make adoption safe and predictable, we’ve delivered a migration path and the compatibility steps needed to move off Management Identity with minimal manual rework. Customers can migrate identity configuration and data with greater confidence, while maintaining continuity across their environments. During and after migration, the platform presents a more consistent mental model for tenants, roles, groups, and authorizations—helping teams avoid the “it works in one place but not another” experience.
We’ve also added basic observability to help teams troubleshoot identity setup and configuration issues more effectively. This is especially valuable for hard-to-diagnose cases where login succeeds but subsequent requests fail, reducing time spent in long investigations and making it easier to pinpoint misconfigurations or mismatched assumptions between components.
User Stories
-
As a platform administrator, I want a single, consistent identity stack across Camunda components. This allows me to configure each Camunda component independently, but in a consistent and predictable way so that I can reduce security risk, confusion, and compliance overhead.
-
As an administrator, I want a clear deprecation timeline and migration plan for Management Identity so that I can schedule upgrades and communicate changes to stakeholders without surprises.
-
As an administrator, I want to migrate identity configuration and data with minimal manual rework so that I can complete the transition quickly and reliably.
-
As a security administrator, I want tenants, roles, groups, and authorizations to behave consistently across components so that I can apply and audit access policies uniformly.
-
As an operator/support engineer, I want basic troubleshooting tools such as logging to debug authentication issues and an identity diagnostics console to debug authorization issues, both for myself or for another user.
Implementation Notes
Key outcomes (what done means):
-
Camunda communicates a clear deprecation timeline and supports migration paths.
-
Customers migrate identity configuration and data with minimal manual rework.
-
The platform behaves consistently across components because it relies on a common identity stack.
-
Provide basic observability capabilities to debug setup and configuration of identity components combatting failures like “login works but requests fail” to avoid long investigations
What will customers be disappointed with?
-
Identity management is still decentralized requiring multiple touch points (e.g. one for each cluster plus one for web-modeller / hub)
-
Lack of a sufficiently fine-grained authorization model in web-modeller
-
Lack of controls for sessions (duration, idle timeouts, ‘immediate’ termination)
-
Applies to Self-Managed but not SaaS
- Authorizations in Hub/Web-Modeler are mostly manual for SaaS customers
-
OIDC only