Skip to main content
Version: 8.1


Operate provides three ways to authenticate:

  1. User information stored in Elasticsearch
  2. Lightweight Directory Access Protocol (LDAP)
  3. Identity Authentication and Authorization

By default, user storage in Elasticsearch is enabled.

User in Elasticsearch

In this mode, the user authenticates with a username and password stored in Elasticsearch.

The Userid, displayName, password, and roles for one user may be set in application.yml:

userId: anUserId
displayName: nameShownInWebpage
password: aPassword

Currently, OPERATOR, OWNER, and USER roles are available.

Roles for users

OWNERFull access
OPERATORRead and write access
USERRead only access

On startup of Operate, the user is created if they did not exist before.

By default, three users are created:

  • Role OWNER with userId/displayName/password demo/demo/demo.
  • Role OPERATOR with userId/displayName/password act/act/act.
  • Role USER with userId/displayName/password view/view/view.

Add more users directly to Elasticsearch via the index operate-user-<version>_. The password must be encoded with a strong bcrypt hashing function.


Enable LDAP

LDAP can only be enabled by setting the Spring profile: ldap-auth.

See the following example for setting the Spring profile as an environmental variable:


Configuration of LDAP

A user can authenticate via LDAP.

The following parameters for connection to an LDAP server should be given:

Parameter nameDescriptionExampleRequired
camunda.operate.ldap.urlURL to an LDAP Serverldaps://
camunda.operate.ldap.baseDnBase domain namedc=camunda,dc=comYes
camunda.operate.ldap.managerDnManager domain used by Operate to log into LDAP server to retrieve user,dc=camunda,dc=comYes
camunda.operate.ldap.managerPasswordPassword for managerYes
camunda.operate.ldap.userSearchFilterFilter to retrieve user info. The pattern '{0}' is replaced by the given username in the login form.{0}No, default is {0}
camunda.operate.ldap.userSearchBaseThe starting point for search.ou=Support,dc=camunda,dc=comNo
camunda.operate.ldap.userIdAttrNameLDAP attribute used to extract user id.userPrincipalNameNo
camunda.operate.ldap.displayNameAttrNameLDAP attribute used to extract username; the name the UI will show.userNameNo
camunda.operate.ldap.userDnPatternsPattern for retrieving user info, similar to userSearchFilter. The pattern '{0}' is replaced by the given username in the login form.uid={0},ou=peopleNo

Example for standard LDAP server:


Configuration of active directory-based LDAP

For an active directory-based LDAP server, an additional parameter should be given:

Parameter nameDescriptionRequired
camunda.operate.ldap.urlURL to an active directory LDAP serverYes
camunda.operate.ldap.baseDnRoot domain nameNo
camunda.operate.ldap.userSearchFilterUsed as a search filterNo

The active directory configuration will only be applied when camunda.operate.ldap.domain is given.

Example for active directory:


userSearchFilter can be empty, and active directory default implementation would get (&(objectClass=user)(userPrincipalName={0})).


Identity provides authentication and authorization functionality along with user management.

Enable Identity

Identity can only be enabled by setting the Spring profile: identity-auth.

See the following example:

export SPRING_PROFILES_ACTIVE=identity-auth

Configure Identity

Identity requires the following parameters:

Parameter nameDescriptionExample value
camunda.operate.identity.issuerUrlURL of issuer (Identity)http://localhost:18080/auth/realms/camunda-platform
camunda.operate.identity.issuerBackendUrlBackend URL of issuer (Identity)http://localhost:18080/auth/realms/camunda-platform
camunda.operate.identity.clientIdSimilar to a username for the applicationoperate
camunda.operate.identity.clientSecretSimilar to a password for the applicationXALaRPl...s7dL7
camunda.operate.identity.audienceAudience for Operateoperate-api issuer URIhttp://localhost:18080/auth/realms/camunda-platform URI to get public keys for JWT validationhttp://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/certs

Use Identity JWT token to access Operate API

Operate provides a REST API under the endpoint /v1. Clients can access this API using a JWT access token in an authorization header Authorization: Bearer <JWT>.


  1. Add an application in Identity.
  2. Add permissions to an application for Operate API.
  3. Obtain a token to access the REST API. You will need:
    • client_id and client_secret from Identity application you created.
    • URL of the authorization server will look like: http://<keycloak_host>:<port>/auth/realms/camunda-platform/protocol/openid-connect/token, where host and port reference Keycloak URL (e.g. localhost:18080).
curl --location --request POST 'http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=<client id>' \
--data-urlencode 'client_secret=<secret>' \
--data-urlencode 'grant_type=client_credentials'

You will get something like the following:

"access_token": "eyJhbG...",
"expires_in": 300,
"refresh_expires_in": 0,
"token_type": "Bearer",
"not-before-policy": 0

Take the access_token value from the response object and store it as your token.

  1. Send the token as an authorization header in each request. In this case, request all process definitions.
curl -X POST 'http://localhost:8080/v1/process-definitions/search' -H 'Content-Type: application/json' -H 'Authorization: Bearer eyJhb...' -d '{}'