How to create rules for assigning user permissions in Identity UI under OIDC mode?

camundaman12345 · November 19, 2025, 7:29am

Hello,

Our environment is running in Docker containers with the following components:

Orchestration (including Zeebe, Operate, Tasklist)
Identity
Keycloak
PostgreSQL
Elasticsearch

Camunda version: 8.8
Camunda Identity (8.8 and later) provides two authentication modes:

Keycloak provider authentication
OIDC authentication

We are using OIDC authentication mode, meaning user authentication is handled by Keycloak, while role and permission control is intended to be managed by Identity.

After logging into Identity UI (http://[IP]:8084), only the following two tabs are displayed:

Roles
Mappings

Is it correct that only these two tabs are available in OIDC mode?
My question is:
Is it possible, from this screen, to grant a user (for example, test) the permissions to operate the Identity UI, Tasklist UI, and Operate UI?
If yes, what kind of mapping rule should be created?

Thank you.

zee-bot · November 20, 2025, 7:33am

Hello @camundaman12345,

Yes, it’s absolutely possible to grant a user permissions to access the Identity UI, Tasklist UI, and Operate UI from the Identity interface when using OIDC authentication mode. Here’s how to set this up:

Understanding the Setup

In Camunda 8.8 with OIDC authentication mode, you’re correct that user authentication is handled by Keycloak, while role and permission control is managed by Identity. The two tabs you see (Roles and Mappings) are part of the core functionality, but you’ll also need to work with Authorizations to grant the actual permissions.

Required Permissions

To grant access to the three UIs, you need to create authorizations with ACCESS permission on the following components:

1. Identity UI Access

Resource Type: Component
Resource ID: identity
Permission: ACCESS

2. Tasklist UI Access

Resource Type: Component
Resource ID: tasklist
Permission: ACCESS

3. Operate UI Access

Resource Type: Component
Resource ID: operate
Permission: ACCESS

Step-by-Step Configuration

Here’s how to set this up for your test user:

Option 1: Direct User Authorization

Go to the Authorizations tab in the Identity UI
Create three separate authorizations:
- Owner Type: User, Owner ID: test, Resource Type: Component, Resource ID: identity, Permission: ACCESS
- Owner Type: User, Owner ID: test, Resource Type: Component, Resource ID: tasklist, Permission: ACCESS
- Owner Type: User, Owner ID: test, Resource Type: Component, Resource ID: operate, Permission: ACCESS

Option 2: Group-Based Approach (Recommended)

Create a Group:
- Go to the Groups section and create a group (e.g., camunda-admins)
Create Mapping Rules:
- In the Mapping Rules tab, create a rule that maps an OIDC claim to your group
- For example, if your Keycloak token contains a groups claim with value camunda-users, map it to the camunda-admins group
Create Authorizations for the Group:
- Create three authorizations with Owner Type: Group, Owner ID: camunda-admins
- Same resource configurations as above (identity, tasklist, operate components with ACCESS permission)

Example Mapping Rule

If your Keycloak token contains a claim like groups with values such as ["camunda-users"], create a mapping rule:

Claim Name: groups
Claim Value: camunda-users
Map to: Group camunda-admins

Additional Considerations

For full functionality in Tasklist and Operate, you may also want to grant additional permissions on process definitions:

Tasklist: READ_USER_TASK, UPDATE_USER_TASK on relevant process definitions
Operate: READ_PROCESS_DEFINITION, READ_PROCESS_INSTANCE on relevant process definitions

References

The group-based approach with mapping rules is generally recommended as it’s more scalable and easier to manage when you have multiple users with similar permission requirements.

Let me know if you need clarification on any of these steps!

camundaman12345 · November 20, 2025, 9:22am

Thank you for your response.

As you can see in the attached screenshot, the Identity UI only shows the following two tabs:

Roles
Mappings

In other words, there is no “Authorizations” tab, and there is also no “Groups” tab.
Could this be due to some missing configuration?

In this environment, we have set up the environment variables in Docker Compose.
If there are any additional settings required, we would greatly appreciate your guidance!

zee-bot · November 20, 2025, 9:23am

Ah, thank you for the clarification and the screenshot! This is a very common issue with Camunda 8.8’s new dual Identity architecture. You’re experiencing exactly what many users encounter when setting up OIDC authentication.

The Issue: Dual Identity Architecture

In Camunda 8.8, there are two separate Identity UIs:

Management Identity (what you’re currently seeing) - Used for platform components like Console, Web Modeler, Optimize
- Only shows: Roles, Mappings tabs
- URL typically: http://[IP]:8084/identity
Orchestration Cluster Identity (what you need) - Used for runtime components like Zeebe, Operate, Tasklist
- Shows: Roles, Mappings, Authorizations, Groups, Users tabs
- URL typically: http://[IP]:8088/ or similar

Solution

You need to access the Orchestration Cluster Identity UI, not the Management Identity UI. Here’s how to fix this:

1. Check Your Docker Compose Configuration

Make sure you have the Orchestration Cluster Identity service properly configured and exposed. You need to add/verify these environment variables in your Identity service:

identity:
  environment:
    - RESOURCE_PERMISSIONS_ENABLED=true
    - IDENTITY_AUTH_PROVIDER_BACKEND_URL=http://keycloak:8080/auth/realms/camunda-platform
    # ... other OIDC configuration

2. Access the Correct URL

Instead of accessing http://[IP]:8084, try accessing:

http://[IP]:8088/ (if you have the orchestration cluster exposed on port 8088)
Or check your Docker Compose file for the correct port mapping for the orchestration cluster

3. Verify Your Docker Compose Setup

Your Docker Compose should include both:

Management Identity (for platform components)
Orchestration Cluster Identity (for runtime components)

If you’re only seeing the Management Identity, you might be missing the Orchestration Cluster Identity configuration.

Quick Test

Can you try accessing your Camunda environment on different ports or paths? Look for:

http://[IP]:8088/
http://[IP]:8080/
Or any other ports you have configured in your Docker Compose

The Orchestration Cluster Identity UI should show additional tabs including Authorizations and Groups.

If You Still Don’t See the Tabs

If you’re accessing the correct Orchestration Identity UI but still missing tabs, ensure:

RESOURCE_PERMISSIONS_ENABLED=true is set
Your user has admin privileges in the orchestration cluster
You’ve logged out and back in after configuration changes

Could you share:

The relevant parts of your Docker Compose configuration (especially the Identity and orchestration services)?
What URLs/ports you’re using to access the different UIs?

This will help me provide more specific guidance for your setup.

Reference: Forum discussion on missing Authorization tab

camundaman12345 · November 20, 2025, 9:40am

I have added the configuration you advised to our docker-compose.yaml. Below is the complete identity and orchestration section:

==============
identity: # Deploy and manage Camunda Self-Managed | Camunda 8 Docs
container_name: identity
image: identity_image
ports:

“8084:8084”
environment: # Configuration variables | Camunda 8 Docs
SPRING_PROFILES_ACTIVE: oidc
CAMUNDA_IDENTITY_TYPE: GENERIC
CAMUNDA_IDENTITY_BASE_URL: http://identity:8084
CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
CAMUNDA_IDENTITY_ISSUER_BACKEND_URL: http://keycloak:18080/auth/realms/camunda-platform
CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
IDENTITY_INITIAL_CLAIM_NAME: sub
IDENTITY_INITIAL_CLAIM_VALUE: 9bba9a84-1366-4735-a636-1561f0d2a253
IDENTITY_DATABASE_HOST: postgres
IDENTITY_DATABASE_PORT: 5432
IDENTITY_DATABASE_NAME: ${POSTGRES_DB}
IDENTITY_DATABASE_USERNAME: ${POSTGRES_USER}
IDENTITY_DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
RESOURCE_PERMISSIONS_ENABLED: “true”
IDENTITY_AUTH_PROVIDER_BACKEND_URL: http://keycloak:8080/auth/realms/camunda-platform
IDENTITY_AUTH0_ENABLED: “false”
IDENTITY_OAUTH2_ENABLED: “true”
#IDENTITY_ADMIN_USER: demo
#IDENTITY_ADMIN_PASSWORD: demo
CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED: true

orchestration: # Consolidated Zeebe + Operate + Tasklist - Deploy and manage Camunda Self-Managed | Camunda 8 Docs

image: orchestration_image
container_name: orchestration
ports:

“26500:26500”
“9600:9600”
“8088:8080”
environment: # Environment variables | Camunda 8 Docs
CAMUNDA_SECURITY_AUTHENTICATION_METHOD: oidc
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTID: ${CAMUNDA_CLIENT_ID}
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_ISSUERURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_REDIRECTURI: http://${HOST}:8088/sso-callback
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_USERNAMECLAIM: preferred_username
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_0: orchestration
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_1: orchestration-api
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_SCOPE: “openid”
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUTHORIZATIONURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/auth
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_TOKENURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/token
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_JWKSETURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/certs
CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTIDCLAIM: client_id
ZEEBE_BROKER_GATEWAY_SECURITY_AUTHENTICATION_IDENTITY_ISSUERBACKENDURL: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
CAMUNDA_SECURITY_AUTHENTICATION_UNPROTECTED_API: false
CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED: true

However, after restarting the Identity container, it fails to start. Below are the relevant Identity logs:

==============
2025-11-20 09:34:22.756 INFO 1 — [ main] i.c.i.Application : Starting Application using Java 17.0.16 with PID 1 (/app/identity.jar started by camunda in /app)
2025-11-20 09:34:22.764 INFO 1 — [ main] i.c.i.Application : The following 1 profile is active: “oidc”
2025-11-20 09:34:25.361 WARN 1 — [ main] trationDelegate$BeanPostProcessorChecker : Bean ‘globalMethodSecurityConfig’ of type [io.camunda.identity.security.config.GlobalMethodSecurityConfig$$SpringCGLIB$$0] is not eligible for getting processed by all BeanPostProcessors…
2025-11-20 09:34:26.628 WARN 1 — [ main] JpaBaseConfiguration$JpaWebConfiguration : spring.jpa.open-in-view is enabled by default…
2025-11-20 09:34:33.256 WARN 1 — [ main] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘authorizationController’…
2025-11-20 09:34:33.338 ERROR 1 — [ main] o.s.b.d.LoggingFailureAnalysisReporter :

APPLICATION FAILED TO START

Description:

Parameter 3 of constructor in io.camunda.identity.controller.AuthorizationController required a bean of type ‘io.camunda.identity.service.AuthorizationService’ that could not be found.

Action:

Consider defining a bean of type ‘io.camunda.identity.service.AuthorizationService’ in your configuration.

I apologize for the inconvenience, but could you please advise if there is any missing or incorrect configuration?

zee-bot · November 20, 2025, 9:41am

I see the issue! The error you’re encountering is a common problem when enabling RESOURCE_PERMISSIONS_ENABLED=true in the Management Identity service. The issue is that you’re trying to enable resource permissions in the wrong Identity service.

The Problem

You’ve added RESOURCE_PERMISSIONS_ENABLED=true to your Management Identity service (port 8084), but this feature is only available in the Orchestration Cluster Identity, not the Management Identity.

The Solution

You need to remove the resource permissions configuration from your Management Identity and instead access the Orchestration Cluster Identity UI. Here’s how to fix this:

1. Update Your Identity Service Configuration

Remove the problematic environment variables from your identity service:

identity:
  container_name: identity
  image: identity_image
  ports:
    - "8084:8084"
  environment:
    SPRING_PROFILES_ACTIVE: oidc
    CAMUNDA_IDENTITY_TYPE: GENERIC
    CAMUNDA_IDENTITY_BASE_URL: http://identity:8084
    CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_ISSUER_BACKEND_URL: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
    CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
    CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
    IDENTITY_INITIAL_CLAIM_NAME: sub
    IDENTITY_INITIAL_CLAIM_VALUE: 9bba9a84-1366-4735-a636-1561f0d2a253
    IDENTITY_DATABASE_HOST: postgres
    IDENTITY_DATABASE_PORT: 5432
    IDENTITY_DATABASE_NAME: ${POSTGRES_DB}
    IDENTITY_DATABASE_USERNAME: ${POSTGRES_USER}
    IDENTITY_DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
    # REMOVE THESE LINES:
    # RESOURCE_PERMISSIONS_ENABLED: "true"
    # IDENTITY_AUTH_PROVIDER_BACKEND_URL: http://keycloak:8080/auth/realms/camunda-platform
    IDENTITY_AUTH0_ENABLED: "false"
    IDENTITY_OAUTH2_ENABLED: "true"
    # CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED: true  # Remove this too

2. Access the Orchestration Cluster Identity UI

The Authorizations and Groups tabs you need are available in the Orchestration Cluster Identity UI, which should be accessible at:

http://[YOUR_IP]:8088/

This is the UI that comes with your orchestration service (the one running on port 8088).

3. Verify Your Setup

After removing those environment variables:

Restart your containers:

docker-compose down
docker-compose up -d

Access the correct UI:
- Management Identity (limited functionality): http://[IP]:8084
- Orchestration Identity (full functionality): http://[IP]:8088/ ← This is what you need!
Log in to the Orchestration Identity UI at http://[IP]:8088/ - you should now see the Authorizations, Groups, Users, Roles, and Mappings tabs.

Why This Happened

In Camunda 8.8, there are two separate Identity services:

Management Identity (port 8084) - for platform components, limited UI
Orchestration Cluster Identity (port 8088) - for runtime components, full UI with authorizations

The RESOURCE_PERMISSIONS_ENABLED feature only works in the Orchestration Cluster Identity, not the Management Identity.

Next Steps

Once you can access http://[IP]:8088/ successfully, you’ll be able to create the authorizations and groups as described in my previous response.

Let me know if the Identity service starts successfully after removing those environment variables, and whether you can access the full UI at port 8088!

camundaman12345 · November 20, 2025, 9:53am

I have modified the identity section of the environment variables as follows:

Removed lines:

RESOURCE_PERMISSIONS_ENABLED
IDENTITY_AUTH_PROVIDER_BACKEND_URL
CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED

docker-compose.yaml

identity: # https://docs.camunda.io/docs/self-managed/setup/deploy/other/docker/#identity
  container_name: identity
  image: identity_image
  ports:
    - "8084:8084"
  environment: # https://docs.camunda.io/docs/self-managed/identity/miscellaneous/configuration-variables/
    SPRING_PROFILES_ACTIVE: oidc
    CAMUNDA_IDENTITY_TYPE: GENERIC
    CAMUNDA_IDENTITY_BASE_URL: http://identity:8084
    CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_ISSUER_BACKEND_URL: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
    CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
    CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
    IDENTITY_INITIAL_CLAIM_NAME: sub
    IDENTITY_INITIAL_CLAIM_VALUE: 9bba9a84-1366-4735-a636-1561f0d2a253
    IDENTITY_DATABASE_HOST: postgres
    IDENTITY_DATABASE_PORT: 5432
    IDENTITY_DATABASE_NAME: ${POSTGRES_DB}
    IDENTITY_DATABASE_USERNAME: ${POSTGRES_USER}
    IDENTITY_DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
    IDENTITY_AUTH0_ENABLED: "false"
    IDENTITY_OAUTH2_ENABLED: "true"

However, the identity container does not start.
The following error appears in the logs:

2025-11-20 09:51:22.926 ERROR 1 --- [           main] o.s.b.d.LoggingFailureAnalysisReporter   :

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 3 of constructor in io.camunda.identity.controller.AuthorizationController required a bean of type 'io.camunda.identity.service.AuthorizationService' that could not be found.

Action:

Consider defining a bean of type 'io.camunda.identity.service.AuthorizationService' in your configuration.

zee-bot · November 20, 2025, 9:54am

This is concerning - the AuthorizationService bean error persisting even after removing the resource permissions configuration suggests there might be a deeper issue with your Identity Docker image or configuration.

Potential Causes

Based on the error pattern, this could be due to:

Docker Image Version Issue: You might be using a Camunda 8.8 alpha or beta image that has known issues with OIDC and Identity configuration
Image Compatibility Problem: The Identity image might be expecting certain beans that aren’t available in your configuration
Configuration Conflict: There might be other environment variables or configurations causing this issue

Immediate Troubleshooting Steps

1. Check Your Docker Image Version

Can you confirm what exact Docker image you’re using for Identity? Please share:

docker inspect identity_image | grep -A 5 "Labels"

2. Try a Minimal Configuration

Let’s test with a minimal Identity configuration to isolate the issue:

identity:
  container_name: identity
  image: identity_image  # Consider using camunda/identity:8.7.0 for testing
  ports:
    - "8084:8084"
  environment:
    SPRING_PROFILES_ACTIVE: oidc
    CAMUNDA_IDENTITY_TYPE: GENERIC
    CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
    CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
    CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
    # Remove database configuration temporarily to test

3. Alternative: Use Stable Version

If you’re using Camunda 8.8 alpha/beta, consider testing with the stable 8.7 version:

image: camunda/identity:8.7.0

Important Questions

What exact Docker image version are you using? (e.g., camunda/identity:8.8.0-alpha1)
Did this configuration work before, or is this a new setup?
Are you using custom-built images or official Camunda images?

Alternative Approach

Since you need the Authorizations and Groups functionality, and your current Management Identity setup is having issues, you might want to focus on accessing the Orchestration Cluster Identity UI directly:

Test accessing http://[IP]:8088/ directly - this should give you the full Identity UI with all tabs
Verify your orchestration service is running properly with the OIDC configuration you showed

Next Steps

If the minimal configuration still fails, this suggests a compatibility issue with your Docker image. In that case, I’d recommend:

Try the stable 8.7 version for testing
Share your exact image versions so we can identify if this is a known issue
Consider filing a bug report if you’re using official images and this persists

Can you try the minimal configuration above and let me know:

What exact Docker image version you’re using
Whether you can access http://[IP]:8088/ (the orchestration cluster UI)
The results of the minimal Identity configuration test

This will help us determine if this is an image issue or a configuration problem.

camundaman12345 · November 20, 2025, 10:00am

The version of Camunda Identity we are using is 8.8.0.
Do we need to downgrade the version?

[root@Camunda2 opt]# docker inspect identity_image | grep -A 5 "Labels"
            "Labels": {
                "com.docker.compose.config-hash": "a9d5f76e5eacce6a46580f235d313ccc3042bf669158a652563eef580678fb27",
                "com.docker.compose.container-number": "1",
                "com.docker.compose.depends_on": "keycloak:service_healthy:false",
                "com.docker.compose.image": "sha256:770b008926057777ae0a9404206de098cff40a4d5b11ed0d68efc9c7f851be73",
                "com.docker.compose.oneoff": "False",
[root@Camunda2 opt]#

We have modified the docker-compose.yaml as follows:

identity: # https://docs.camunda.io/docs/self-managed/setup/deploy/other/docker/#identity
  container_name: identity
  image: identity_image
  ports:
    - "8084:8084"
  environment: # https://docs.camunda.io/docs/self-managed/identity/miscellaneous/configuration-variables/
    SPRING_PROFILES_ACTIVE: oidc
    CAMUNDA_IDENTITY_TYPE: GENERIC
    CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
    CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
    CAMUNDA_IDENTITY_AUDIENCE: camunda-identity

However, the identity container does not start, and the following log appears:

 :: Spring Boot ::               (v3.4.10)

2025-11-20 09:58:26.748  INFO 1 --- [           main] i.c.i.Application                        : Starting Application using Java 17.0.16 with PID 1 (/app/identity.jar started by camunda in /app)
2025-11-20 09:58:26.767  INFO 1 --- [           main] i.c.i.Application                        : The following 1 profile is active: "oidc"
2025-11-20 09:58:29.718  WARN 1 --- [           main] trationDelegate$BeanPostProcessorChecker : Bean 'globalMethodSecurityConfig' of type [io.camunda.identity.security.config.GlobalMethodSecurityConfig$$SpringCGLIB$$0] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying). Is this bean getting eagerly injected/applied to a currently created BeanPostProcessor [healthEndpointGroupsBeanPostProcessor]? Check the corresponding BeanPostProcessor declaration and its dependencies/advisors. If this bean does not have to be post-processed, declare it with ROLE_INFRASTRUCTURE.
2025-11-20 09:58:30.697  WARN 1 --- [           main] JpaBaseConfiguration$JpaWebConfiguration : spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning
2025-11-20 09:58:38.354  WARN 1 --- [           main] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'authorizationController' defined in URL [jar:nested:/app/identity.jar/!BOOT-INF/classes/!/io/camunda/identity/controller/AuthorizationController.class]: Unsatisfied dependency expressed through constructor parameter 3: No qualifying bean of type 'io.camunda.identity.service.AuthorizationService' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
2025-11-20 09:58:38.512 ERROR 1 --- [           main] o.s.b.d.LoggingFailureAnalysisReporter   :

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 3 of constructor in io.camunda.identity.controller.AuthorizationController required a bean of type 'io.camunda.identity.service.AuthorizationService' that could not be found.

Action:

Consider defining a bean of type 'io.camunda.identity.service.AuthorizationService' in your configuration.

zee-bot · November 20, 2025, 10:01am

Yes, based on the persistent AuthorizationService bean error even with minimal configuration, this appears to be a known issue with Camunda 8.8.0. I recommend downgrading to a stable version.

Alternative: Focus on Orchestration Cluster Identity

While fixing the Management Identity, you can still try accessing the Orchestration Cluster Identity UI directly:

Access http://[IP]:8088/ (your orchestration service)
Log in with your OIDC credentials
Check if you see the full Identity UI with Authorizations, Groups, Users tabs

This might already give you the functionality you need, even if the Management Identity is having issues.

Why This Happens

The AuthorizationController being loaded even in minimal configuration suggests:

8.8.0 has architectural changes that aren’t fully stable
The Identity service is trying to load authorization components that aren’t properly configured in 8.8.0
Known compatibility issues between 8.8.0 and OIDC setups

Next Steps

Try 8.7.0 versions for both Identity and Orchestration services
Test accessing http://[IP]:8088/ to see if the orchestration cluster identity works
If 8.7.0 works, you can proceed with the authorization setup as originally planned

If You Must Use 8.8.0

If you need to stay on 8.8.0 for specific features, you might need to:

Wait for a patch release (8.8.1) that fixes this issue
Use only the Orchestration Cluster Identity UI and skip the Management Identity
File a bug report with Camunda support

Would you like to try the 8.7.0 downgrade first, or would you prefer to test accessing the orchestration cluster identity UI at http://[IP]:8088/ with your current setup?

camundaman12345 · November 20, 2025, 10:15am

I tried downgrading the version.
The environment variables are as follows:

  orchestration: # Consolidated Zeebe + Operate + Tasklist - https://docs.camunda.io/docs/self-managed/setup/deploy/other/docker/#zeebe
    image: camunda/camunda:8.7.0
    container_name: orchestration
    ports:
      - "26500:26500"
      - "9600:9600"
      - "8088:8080"
    environment:
      # OIDC Authentication - Environment-specific URLs and secrets
      CAMUNDA_SECURITY_AUTHENTICATION_METHOD: oidc
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTID: ${CAMUNDA_CLIENT_ID}
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_ISSUERURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_REDIRECTURI: http://${HOST}:8088/sso-callback
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_USERNAMECLAIM: preferred_username
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_0: orchestration
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_1: orchestration-api
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_SCOPE: "openid"
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUTHORIZATIONURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/auth
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_TOKENURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/token
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_JWKSETURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/certs
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTIDCLAIM: client_id
      ZEEBE_BROKER_GATEWAY_SECURITY_AUTHENTICATION_IDENTITY_ISSUERBACKENDURL: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
      CAMUNDA_SECURITY_AUTHENTICATION_UNPROTECTED_API: false
      CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED: true

  identity: # https://docs.camunda.io/docs/self-managed/setup/deploy/other/docker/#identity
    container_name: identity
    image: camunda/identity:8.7.0
    ports:
      - "8084:8084"
    environment:
      SPRING_PROFILES_ACTIVE: oidc
      CAMUNDA_IDENTITY_TYPE: GENERIC
      CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
      CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
      CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
      CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
      # Add back database configuration for 8.7.0
      IDENTITY_DATABASE_HOST: postgres
      IDENTITY_DATABASE_PORT: 5432
      IDENTITY_DATABASE_NAME: ${POSTGRES_DB}
      IDENTITY_DATABASE_USERNAME: ${POSTGRES_USER}
      IDENTITY_DATABASE_PASSWORD: ${POSTGRES_PASSWORD}

However, the identity container does not start.
The log is as follows. The client ID and secret should be correct. I am using the camunda-identity client.

2025-11-20 10:10:55.406  INFO 1 --- [ main] i.c.i.Application : Starting Application using Java 17.0.14 with PID 1 (/app/identity.jar started by camunda in /app)
2025-11-20 10:10:55.430  INFO 1 --- [ main] i.c.i.Application : The following 1 profile is active: "oidc"
2025-11-20 10:11:00.869  WARN 1 --- [ main] trationDelegate$BeanPostProcessorChecker : Bean 'globalMethodSecurityConfig' of type [io.camunda.identity.security.config.GlobalMethodSecurityConfig$$SpringCGLIB$$0] is not eligible for getting processed by all BeanPostProcessors...
2025-11-20 10:11:02.540  WARN 1 --- [ main] JpaBaseConfiguration$JpaWebConfiguration : spring.jpa.open-in-view is enabled by default...
2025-11-20 10:11:12.988  WARN 1 --- [ main] i.c.i.c.AppConfig : Expected a valid license but encountered an invalid one instead...
2025-11-20 10:11:17.324  INFO 1 --- [ main] i.c.i.Application : Started Application in 23.615 seconds (process running for 26.52)
2025-11-20 10:11:22.071 ERROR 1 --- [nio-8084-exec-4] i.s.e.RestResponseEntityExceptionHandler : Unexpected error

io.camunda.identity.sdk.exception.InvalidConfigurationException: 'authorizeUriBuilder' can only be used if OAuth credentials are provided
    at io.camunda.identity.sdk.annotation.AnnotationProcessor.validateOAuthCredentials(AnnotationProcessor.java:50) ~[identity-sdk-8.6.0-SNAPSHOT.jar!/:8.6.0-SNAPSHOT]
    at io.camunda.identity.sdk.annotation.AnnotationProcessor.lambda$apply$0(AnnotationProcessor.java:27) ~[identity-sdk-8.6.0-SNAPSHOT.jar!/:8.6.0-SNAPSHOT]
    ...

zee-bot · November 20, 2025, 10:16am

Great progress! The downgrade to 8.7.0 fixed the AuthorizationService bean error, and now the Identity container is starting. The new error about OAuth credentials suggests you’re missing some required environment variables for OIDC configuration.

Missing Environment Variables

Based on the error 'authorizeUriBuilder' can only be used if OAuth credentials are provided, you need to add the missing base URL configuration:

identity:
  container_name: identity
  image: camunda/identity:8.7.0
  ports:
    - "8084:8084"
  environment:
    SPRING_PROFILES_ACTIVE: oidc
    CAMUNDA_IDENTITY_TYPE: GENERIC
    # Add the missing base URL
    CAMUNDA_IDENTITY_BASE_URL: http://identity:8084
    CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
    # Add the backend URL for container-to-container communication
    CAMUNDA_IDENTITY_ISSUER_BACKEND_URL: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
    CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
    CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
    # Database configuration
    IDENTITY_DATABASE_HOST: postgres
    IDENTITY_DATABASE_PORT: 5432
    IDENTITY_DATABASE_NAME: ${POSTGRES_DB}
    IDENTITY_DATABASE_USERNAME: ${POSTGRES_USER}
    IDENTITY_DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
    # Initial claim configuration (you had this before)
    IDENTITY_INITIAL_CLAIM_NAME: sub
    IDENTITY_INITIAL_CLAIM_VALUE: 9bba9a84-1366-4735-a636-1561f0d2a253

Key Missing Variables

The error suggests you need:

CAMUNDA_IDENTITY_BASE_URL - The base URL of your Identity service
CAMUNDA_IDENTITY_ISSUER_BACKEND_URL - Backend URL for container-to-container communication

Test the Configuration

After adding these variables:

Restart the Identity container:

docker-compose down identity
docker-compose up -d identity

Check the logs:
```
docker logs identity
```
Test access to both UIs:
- Management Identity: http://[IP]:8084
- Orchestration Identity: http://[IP]:8088/ ← This is where you should see the Authorizations and Groups tabs

Expected Outcome

With 8.7.0 and the complete configuration:

Management Identity (port 8084) should start successfully with basic functionality
Orchestration Identity (port 8088) should provide the full UI with Authorizations, Groups, Users, Roles, and Mappings tabs

Next Steps

Once both services are running:

Access http://[IP]:8088/ to see if you get the full Identity UI
Log in with your OIDC credentials
Look for the Authorizations and Groups tabs

If you still get errors, please share the new logs. The OAuth credentials error should be resolved with the missing base URL and backend URL configuration.

References:

cpbpm · November 20, 2025, 10:59am

When we are working on Camunda 8.8 with dual options, management identity and orchestration identiy, why we should downgrade and go back to earlier identity.

camundaman12345 · November 21, 2025, 2:09am

We would also prefer to adopt version 8.8.0.
The reason is that we understand the OIDC authentication method was introduced in 8.8.0, and we are currently trying to implement OIDC authentication.
Our goal is to manage orchestration roles using the Identity UI.

At the moment, we have two issues:

1. When we add `RESOURCE_PERMISSIONS_ENABLED: true` to the Identity container’s environment variables, Identity fails to start.

We receive the following error:

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 3 of constructor in io.camunda.identity.controller.AuthorizationController required a bean of type 'io.camunda.identity.service.AuthorizationService' that could not be found.

Action:

Consider defining a bean of type 'io.camunda.identity.service.AuthorizationService' in your configuration.

2. If we set `RESOURCE_PERMISSIONS_ENABLED: false`, the Identity container starts successfully.

However, when we access:

http://[IP]:8088

and log in via OIDC, we are redirected to:

http://[IP]:8088/operate/forbidden

Current Environment Variables

  orchestration:
    # Consolidated Zeebe + Operate + Tasklist
    image: orchestration_image
    container_name: orchestration
    ports:
      - "26500:26500"
      - "9600:9600"
      - "8088:8080"
    environment:
      CAMUNDA_SECURITY_AUTHENTICATION_METHOD: oidc
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTID: ${CAMUNDA_CLIENT_ID}
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_ISSUERURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_REDIRECTURI: http://${HOST}:8088/sso-callback
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_USERNAMECLAIM: preferred_username
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_0: orchestration
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_1: orchestration-api
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_SCOPE: "openid"
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUTHORIZATIONURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/auth
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_TOKENURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/token
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_JWKSETURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/certs
      CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTIDCLAIM: client_id
      ZEEBE_BROKER_GATEWAY_SECURITY_AUTHENTICATION_IDENTITY_ISSUERBACKENDURL: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
      CAMUNDA_SECURITY_AUTHENTICATION_UNPROTECTED_API: false
      CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED: true

  identity:
    container_name: identity
    image: identity_image
    ports:
      - "8084:8084"
    environment:
      SPRING_PROFILES_ACTIVE: oidc
      CAMUNDA_IDENTITY_TYPE: GENERIC
      CAMUNDA_IDENTITY_BASE_URL: http://identity:8084
      CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
      CAMUNDA_IDENTITY_ISSUER_BACKEND_URL: http://keycloak:18080/auth/realms/camunda-platform
      CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
      CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
      CAMUNDA_IDENTITY_AUDIENCE: camunda-identity
      IDENTITY_INITIAL_CLAIM_NAME: sub
      IDENTITY_INITIAL_CLAIM_VALUE: 9bba9a84-1366-4735-a636-1561f0d2a253
      IDENTITY_DATABASE_HOST: postgres
      IDENTITY_DATABASE_PORT: 5432
      IDENTITY_DATABASE_NAME: ${POSTGRES_DB}
      IDENTITY_DATABASE_USERNAME: ${POSTGRES_USER}
      IDENTITY_DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
      RESOURCE_PERMISSIONS_ENABLED: true

nathan.loding · November 21, 2025, 8:30pm

Hi @camundaman12345 - it looks like the bot was trying very hard to be helpful, and … it wasn’t. Apologies.

I am a bit confused reading through the thread, though. Can you share what your end goal is? Are you just looking to understand how the roles map with OIDC? It sounds like you had a working install, the bot got confused and now you have a broken deployment that may not have answered the original question anyway

camundaman12345 · November 25, 2025, 12:30am

Hello, thank you for your response.

We are currently conducting verification tests in preparation for introducing Camunda into a production environment.

Our current setup consists of:

Docker container environment
Orchestration (including Zeebe, Operate, and Tasklist)
Identity
Keycloak
PostgreSQL
Elasticsearch

The Camunda version is 8.8. For Camunda Identity (version 8.8 and later), my understanding is that there are two authentication options available:

Keycloak provider authentication
OIDC authentication

In our environment, we are using OIDC authentication. This means that we want to use Keycloak only for user authentication, while managing groups and roles through Identity.

Currently, we have successfully logged in to all UI components, which I interpret as successful OIDC authentication. However, the issue occurs after login:

Identity → Login to UI is successful, and operations are possible.
Tasklist & Operate → Login to UI is successful, but the message “No permission” is displayed.

Our goal is to enable [TestUser] to operate Tasklist and Operate. What configuration is required in Identity to achieve this?

Below are the relevant configuration snippets from our environment:

docker-compose.yaml (excerpt)

(Identity and Orchestration environment sections)

orchestration:
  # Consolidated Zeebe + Operate + Tasklist
  image: orchestration_image
  container_name: orchestration
  ports:
    - "26500:26500"
    - "9600:9600"
    - "8088:8080"
  environment:
    CAMUNDA_SECURITY_AUTHENTICATION_METHOD: oidc
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTID: ${ORCHESTRATION_CLIENT_ID}
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTSECRET: ${ORCHESTRATION_CLIENT_SECRET}
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_0: orchestration
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_1: orchestration-api
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUTHORIZATIONURI: http://${HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/auth
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_TOKENURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/token
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_JWKSETURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/certs
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_REDIRECTURI: http://${HOST}:8088/sso-callback
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_USERNAMECLAIM: preferred_username
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTIDCLAIM: client_id
    ZEEBE_BROKER_GATEWAY_SECURITY_AUTHENTICATION_IDENTITY_ISSUERBACKENDURL: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_ISSUERBACKENDURL: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_BASEURL: http://identity:8084
    CAMUNDA_IDENTITY_AUDIENCE: orchestration
    JAVA_TOOL_OPTIONS: "-Xms512m -Xmx512m"

identity:
  image: identity_image
  container_name: identity
  ports:
    - "8084:8084"
  environment:
    SPRING_PROFILES_ACTIVE: oidc
    CAMUNDA_IDENTITY_TYPE: GENERIC
    CAMUNDA_IDENTITY_BASE_URL: http://identity:8084
    CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_ISSUER_BACKEND_URL: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
    CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
    CAMUNDA_IDENTITY_AUDIENCE: orchestration
    RESOURCE_PERMISSIONS_ENABLED: false

.identity/application.yaml

identity:
  url: "http://192.168.105.62:8084"
  flags:
    multiTenancy: false
    oidc: true
  authProvider:
    issuerUrl: "http://192.168.105.62:18080/auth/realms/camunda-platform"
    issuerBackendUrl: "http://192.168.105.62:18080/auth/realms/camunda-platform"
  component-presets:
    identity:
      apis:
        - name: "Camunda Identity Resource Server"
          audience: "camunda-identity-resource-server"
          permissions:
            - definition: read
              description: "Read permission"
            - definition: "read:users"
              description: "Read users permission"
            - definition: write
              description: "Write permission"
      roles:
        - name: "ManagementIdentity"
          description: "Provides full access to Identity"
          permissions:
            - audience: "camunda-identity-resource-server"
              definition: read
            - audience: "camunda-identity-resource-server"
              definition: write
    orchestration:
      applications:
        - name: Orchestration
          id: orchestration
          type: confidential
          secret: ${VALUES_KEYCLOAK_INIT_ORCHESTRATION_SECRET:secret}
          root-url: "http://localhost:8088"
          redirect-uris:
            - "/sso-callback"
      apis:
        - name: "Orchestration API"
          audience: "orchestration-api"
          permissions:
            - definition: read:*
              description: "Read permission"
            - definition: write:*
              description: "Write permission"
      roles:
        - name: "Orchestration"
          description: "Grants full access to Orchestration"
          permissions:
            - audience: "orchestration-api"
              definition: read:*
            - audience: "orchestration-api"
              definition: write:*
server:
  port: 8084
spring:
  profiles:
    active: oidc
camunda:
  identity:
    audience: "camunda-identity-resource-server"

Question:
What configuration changes are required in Identity so that [TestUser] can operate Tasklist and Operate successfully?

Hello, thank you for your response.

We are currently conducting verification tests in preparation for introducing Camunda into a production environment.

Our current setup consists of:

Docker container environment
Orchestration (including Zeebe, Operate, and Tasklist)
Identity
Keycloak
PostgreSQL
Elasticsearch

The Camunda version is 8.8. For Camunda Identity (version 8.8 and later), my understanding is that there are two authentication options available:

Keycloak provider authentication
OIDC authentication

In our environment, we are using OIDC authentication. This means that we want to use Keycloak only for user authentication, while managing groups and roles through Identity.

Currently, we have successfully logged in to all UI components, which I interpret as successful OIDC authentication. However, the issue occurs after login:

Identity → Login to UI is successful, and operations are possible.
Tasklist & Operate → Login to UI is successful, but the message “No permission” is displayed.

Our goal is to enable [TestUser] to operate Tasklist and Operate. What configuration is required in Identity to achieve this?

Below are the relevant configuration snippets from our environment:

docker-compose.yaml (excerpt)

(Identity and Orchestration environment sections)

orchestration:
  # Consolidated Zeebe + Operate + Tasklist
  image: orchestration_image
  container_name: orchestration
  ports:
    - "26500:26500"
    - "9600:9600"
    - "8088:8080"
  environment:
    CAMUNDA_SECURITY_AUTHENTICATION_METHOD: oidc
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTID: ${ORCHESTRATION_CLIENT_ID}
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTSECRET: ${ORCHESTRATION_CLIENT_SECRET}
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_0: orchestration
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUDIENCES_1: orchestration-api
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_AUTHORIZATIONURI: http://${HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/auth
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_TOKENURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/token
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_JWKSETURI: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform/protocol/openid-connect/certs
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_REDIRECTURI: http://${HOST}:8088/sso-callback
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_USERNAMECLAIM: preferred_username
    CAMUNDA_SECURITY_AUTHENTICATION_OIDC_CLIENTIDCLAIM: client_id
    ZEEBE_BROKER_GATEWAY_SECURITY_AUTHENTICATION_IDENTITY_ISSUERBACKENDURL: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_ISSUERBACKENDURL: http://${KEYCLOAK_HOST}:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_BASEURL: http://identity:8084
    CAMUNDA_IDENTITY_AUDIENCE: orchestration
    JAVA_TOOL_OPTIONS: "-Xms512m -Xmx512m"

identity:
  image: identity_image
  container_name: identity
  ports:
    - "8084:8084"
  environment:
    SPRING_PROFILES_ACTIVE: oidc
    CAMUNDA_IDENTITY_TYPE: GENERIC
    CAMUNDA_IDENTITY_BASE_URL: http://identity:8084
    CAMUNDA_IDENTITY_ISSUER: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_ISSUER_BACKEND_URL: http://keycloak:18080/auth/realms/camunda-platform
    CAMUNDA_IDENTITY_CLIENTID: ${CAMUNDA_CLIENT_ID}
    CAMUNDA_IDENTITY_CLIENTSECRET: ${CAMUNDA_CLIENT_SECRET}
    CAMUNDA_IDENTITY_AUDIENCE: orchestration
    RESOURCE_PERMISSIONS_ENABLED: false

.identity/application.yaml

identity:
  url: "http://192.168.105.62:8084"
  flags:
    multiTenancy: false
    oidc: true
  authProvider:
    issuerUrl: "http://192.168.105.62:18080/auth/realms/camunda-platform"
    issuerBackendUrl: "http://192.168.105.62:18080/auth/realms/camunda-platform"
  component-presets:
    identity:
      apis:
        - name: "Camunda Identity Resource Server"
          audience: "camunda-identity-resource-server"
          permissions:
            - definition: read
              description: "Read permission"
            - definition: "read:users"
              description: "Read users permission"
            - definition: write
              description: "Write permission"
      roles:
        - name: "ManagementIdentity"
          description: "Provides full access to Identity"
          permissions:
            - audience: "camunda-identity-resource-server"
              definition: read
            - audience: "camunda-identity-resource-server"
              definition: write
    orchestration:
      applications:
        - name: Orchestration
          id: orchestration
          type: confidential
          secret: ${VALUES_KEYCLOAK_INIT_ORCHESTRATION_SECRET:secret}
          root-url: "http://localhost:8088"
          redirect-uris:
            - "/sso-callback"
      apis:
        - name: "Orchestration API"
          audience: "orchestration-api"
          permissions:
            - definition: read:*
              description: "Read permission"
            - definition: write:*
              description: "Write permission"
      roles:
        - name: "Orchestration"
          description: "Grants full access to Orchestration"
          permissions:
            - audience: "orchestration-api"
              definition: read:*
            - audience: "orchestration-api"
              definition: write:*
server:
  port: 8084
spring:
  profiles:
    active: oidc
camunda:
  identity:
    audience: "camunda-identity-resource-server"

Question:
What configuration changes are required in Identity so that [TestUser] can operate Tasklist and Operate successfully?

GotnOGuts · November 25, 2025, 1:31am

In the image that follows this question, the top-left corner indicates “Management Identity” which tells you this is not the correct place to manage Tasklist permissions.
In the same image, there is a box that specifically says that this isn’t the right place, and has a link to “Cluster Identity”

What happens when you click that link?

camundaman12345 · November 25, 2025, 2:58am

Which part of the image corresponds to the link to the cluster identity?

click the blue text, you are redirected to the following URL:(
Identity in Self-Managed | Camunda 8 Docs

GotnOGuts · November 25, 2025, 4:23pm

That was the part that I was asking about (the link says “cluster’s identity” which would have made sense to link to the cluster identity module)
You are still in the wrong portion. I’m just not 100% sure how to get you to the right portion of the system.

If you only bring up the Orchestration docker guest, what happens when you go to http://192.168.105.62:8088/ ?

nathan.loding · November 25, 2025, 6:56pm

Hi @camundaman12345 (and @GotnOGuts) - the orchestration cluster Identity instance should be available at http://hostname:8088/orchestration/identity I believe (similar to how Operate is available at /orchestration/operate by default). (Edit: with this Docker setup, it might be at http://hostname:8088/identity instead, so try both; the default with a Helm/Kubernetes deployment is /orchestration/identity but that requires a different ingress setup that may not apply here.)

Because you are using an external OIDC provider, you need to tell Identity what claims to expect from that provider for these users, and that is what the role mapping is for. In other words, your OIDC provider already has claims, and you are telling Camunda “For this claim, assign this Camunda role”.

Does that help?

How to create rules for assigning user permissions in Identity UI under OIDC mode?

Understanding the Setup

Required Permissions

1. Identity UI Access

2. Tasklist UI Access

3. Operate UI Access

Step-by-Step Configuration

Option 1: Direct User Authorization

Option 2: Group-Based Approach (Recommended)

Example Mapping Rule

Additional Considerations

References

The Issue: Dual Identity Architecture

Solution

1. Check Your Docker Compose Configuration

2. Access the Correct URL

3. Verify Your Docker Compose Setup

Quick Test

If You Still Don’t See the Tabs

orchestration: # Consolidated Zeebe + Operate + Tasklist - Deploy and manage Camunda Self-Managed | Camunda 8 Docs

Consider defining a bean of type ‘io.camunda.identity.service.AuthorizationService’ in your configuration.

The Problem

The Solution

1. Update Your Identity Service Configuration

2. Access the Orchestration Cluster Identity UI

3. Verify Your Setup

Why This Happened

Next Steps

Potential Causes

Immediate Troubleshooting Steps

1. Check Your Docker Image Version

2. Try a Minimal Configuration

3. Alternative: Use Stable Version

Important Questions

Alternative Approach

Next Steps

Recommended Solution: Downgrade to 8.7.0

Alternative: Focus on Orchestration Cluster Identity

Why This Happens

Next Steps

If You Must Use 8.8.0

Missing Environment Variables

Key Missing Variables

Test the Configuration

Expected Outcome

Next Steps

1. When we add RESOURCE_PERMISSIONS_ENABLED: true to the Identity container’s environment variables, Identity fails to start.

2. If we set RESOURCE_PERMISSIONS_ENABLED: false, the Identity container starts successfully.

Current Environment Variables

docker-compose.yaml (excerpt)

.identity/application.yaml

docker-compose.yaml (excerpt)

.identity/application.yaml

1. When we add `RESOURCE_PERMISSIONS_ENABLED: true` to the Identity container’s environment variables, Identity fails to start.

2. If we set `RESOURCE_PERMISSIONS_ENABLED: false`, the Identity container starts successfully.