Management and modeling component authentication in Self-Managed
Optimize authenticates with the same camunda.security.* settings as the Orchestration Cluster. Camunda Hub keeps its own authentication properties in 8.10; see Camunda Hub authentication for details.
User, group, role, tenant, and permission management for Camunda Hub and Optimize stays in Management Identity. The Orchestration Cluster is not affected, because it manages its own users, groups, roles, and authorizations.
Authentication and user management
Authentication and user management are handled separately:
| Concern | Handled by |
|---|---|
| Authenticating users and clients | The component itself. Optimize uses camunda.security.authentication.*, and Camunda Hub uses its own properties. |
| Managing users, groups, roles, tenants, and permissions | Management Identity |
| Storing user identities and issuing tokens | Your Identity Provider (IdP) |
Management Identity is still required for the management and modeling components. For more information, see manage access and permissions.
For the Camunda Hub authentication settings, see authentication.
Choose an Identity Provider setup
Authentication relies on the OpenID Connect (OIDC) and OAuth 2.0 protocols. Where your user identities live, and which IdP issues tokens, is a separate choice from how authentication is configured.
Three primary setups are supported:
- Use Keycloak as the default Identity Provider (IdP).
- Configure Keycloak to connect to an external IdP.
- Connect directly to an external OIDC IdP.
Use Keycloak as the default IdP
Management Identity uses Keycloak as its Identity Provider (IdP) by default. With Helm, Keycloak is an option. The Helm default is Basic authentication. See Helm chart authentication and authorization.
The following table shows which installation methods start Management Identity and Keycloak. For the Docker Compose files, see choose a Docker Compose configuration.
| Installation method | Starts Management Identity | Starts Keycloak |
|---|---|---|
Docker Compose, full (docker-compose-full.yaml) | Yes | Yes |
Docker Compose, standalone Camunda Hub (docker-compose-hub.yaml) | Yes | Yes |
Docker Compose, lightweight (docker-compose.yaml) | No | No |
| Helm | Yes, when you set identity.enabled: true. The default is false. | No. The chart doesn't deploy Keycloak. Deploy it with the Keycloak operator and connect the Helm chart to it. |
In this setup:
- User authentication: Users log in through the Keycloak's login page.
- Application authentication: Applications authenticate using Machine-to-Machine (M2M) tokens.
- User management: Users are managed in Keycloak. Groups, roles, and permissions are managed in Management Identity.
This method is convenient for getting started quickly and is suitable for environments that do not need to integrate with an existing corporate identity management system.
For more information, see connect to an existing Keycloak instance.
Connect to an external IdP via Keycloak
You can configure Keycloak to act as an identity broker, connecting to an external corporate Identity Provider. This allows you to leverage your existing user base from providers that support protocols like SAML, LDAP, or OpenID Connect.
In this setup, Keycloak remains the direct IdP for Camunda management and modeling components, but it delegates the authentication process to your configured external provider.
- User authentication: Users are redirected from Keycloak's login page to your external IdP.
- User management: Users are managed in your external IdP and federated into Keycloak.
- Application authentication: Applications use M2M tokens issued by Keycloak.
This method is useful when you need to integrate with an IdP that does not use OIDC, or when you want to use Keycloak's advanced features to manage roles and map claims from your external provider.
For more information, see configure an external IdP using Keycloak.
Connect to an external OIDC IdP
You can connect the management and modeling components to an external Identity Provider (IdP) that supports OpenID Connect (OIDC) (e.g., Microsoft Entra ID, Keycloak, Auth0, Okta).
In this setup:
- Users are managed in your external IdP.
- User groups from your IdP can be used to manage permissions.
- Clients for M2M authentication are managed in your external IdP.
If you have configured the authentication to Orchestration Cluster with an external OIDC provider, we recommend using the same provider for the management and modeling components. Optimize reads the same camunda.security.authentication.oidc.* settings, so you maintain one authentication configuration and manage users in one place. Camunda Hub connects to the same provider through its own properties; see Camunda Hub authentication.
For more information, see connect Management Identity to an external IdP.