Identity Service

The identity service is an API abstraction over various user/group repositories. The basic entities are

  • User: a user identified by a unique Id
  • Group: a group identified by a unique Id
  • Membership: the relationship between users and groups
  • Tenant: a tenant identified by a unique Id
  • Tenant Membership: the relationship between tenants and users/groups


User demoUser = processEngine.getIdentityService()

Camunda BPM distinguishes between read-only and writable user repositories. A read-only user repository provides read-only access to the underlying user/group database. A writable user repository allows write access to the user database which includes creating, updating and deleting users and groups.

To provide a custom identity provider implementation, the following interfaces can be implemented:

The Database Identity Service

The database identity service uses the process engine database for managing users and groups. This is the default identity service implementation used if no alternative identity service implementation is provided.

The database identity service implements both ReadOnlyIdentityProvider and WritableIdentityProvider providing full CRUD functionality in Users, Groups and Memberships.

The LDAP Identity Service

The LDAP identity service provides read-only access to an LDAP-based user/group repository. The identity service provider is implemented as a Process Engine Plugin and can be added to the process engine configuration. In that case it replaces the default database identity service.

To use the LDAP identity service, the camunda-identity-ldap.jar library has to be added to the classloader of the process engine.

Please import the Camunda BOM to ensure correct versions for every Camunda project.


Activate the LDAP Plugin

The following is an example of how to configure the LDAP Identity Provider Plugin using Spring XML:

<beans xmlns=""
  <bean id="processEngineConfiguration" class="org.camunda.bpm.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration">
    <property name="processEnginePlugins">
        <ref bean="ldapIdentityProviderPlugin" />
  <bean id="ldapIdentityProviderPlugin" class="org.camunda.bpm.identity.impl.ldap.plugin.LdapIdentityProviderPlugin">
    <property name="serverUrl" value="ldap://localhost:3433/" />
    <property name="managerDn" value="uid=daniel,ou=office-berlin,o=camunda,c=org" />
    <property name="managerPassword" value="daniel" />
    <property name="baseDn" value="o=camunda,c=org" />

    <property name="userSearchBase" value="" />
    <property name="userSearchFilter" value="(objectclass=person)" />
    <property name="userIdAttribute" value="uid" />
    <property name="userFirstnameAttribute" value="cn" />
    <property name="userLastnameAttribute" value="sn" />
    <property name="userEmailAttribute" value="mail" />
    <property name="userPasswordAttribute" value="userpassword" />

    <property name="groupSearchBase" value="" />
    <property name="groupSearchFilter" value="(objectclass=groupOfNames)" />
    <property name="groupIdAttribute" value="ou" />
    <property name="groupNameAttribute" value="cn" />
    <property name="groupMemberAttribute" value="member" />

    <property name="authorizationCheckEnabled" value="false" />

The following is an example of how to configure the LDAP Identity Provider Plugin in bpm-platform.xml/processes.xml:

<process-engine name="default">



        <property name="serverUrl">ldap://localhost:4334/</property>
        <property name="managerDn">uid=jonny,ou=office-berlin,o=camunda,c=org</property>
        <property name="managerPassword">s3cr3t</property>

        <property name="baseDn">o=camunda,c=org</property>

        <property name="userSearchBase"></property>
        <property name="userSearchFilter">(objectclass=person)</property>

        <property name="userIdAttribute">uid</property>
        <property name="userFirstnameAttribute">cn</property>
        <property name="userLastnameAttribute">sn</property>
        <property name="userEmailAttribute">mail</property>
        <property name="userPasswordAttribute">userpassword</property>

        <property name="groupSearchBase"></property>
        <property name="groupSearchFilter">(objectclass=groupOfNames)</property>
        <property name="groupIdAttribute">ou</property>
        <property name="groupNameAttribute">cn</property>

        <property name="groupMemberAttribute">member</property>

        <property name="authorizationCheckEnabled">false</property>



Administrator Authorization Plugin

The LDAP Identity Provider Plugin is usually used in combination with the Administrator Authorization Plugin which allows you to grant administrator authorizations for a particular LDAP User/Group.


Currently, the LDPA Identity Service doesn’t support multi-tenancy. That means it is not possible to get tenants from LDAP and the transparent multi-tenancy access restrictions don’t work by default.

Configuration Properties of the LDAP Plugin

The LDAP Identity Provider provides the following configuration properties:

Property Description
serverUrl The url of the LDAP server to connect to.
managerDn The absolute DN of the manager user of the LDAP directory.
managerPassword The password of the manager user of the LDAP directory

The base DN: Identifies the root of the LDAP directory. Is appended to all DN names composed for searching for users or groups.

Example: o=camunda,c=org


Identifies the node in the LDAP tree under which the plugin should search for users. Must be relative to baseDn.

Example: ou=employees


LDAP query string used when searching for users. Example: (objectclass=person)


Name of the user Id property. Example: uid


Name of the firstname property. Example: cn


Name of the lastname property. Example: sn


Name of the email property. Example: mail


Name of the password property. Example: userpassword


Identifies the node in the LDAP tree under which the plugin should search for groups. Must be relative to baseDn.

Example: ou=roles


LDAP query string used when searching for groups. Example: (objectclass=groupOfNames)


Name of the group Id property. Example: ou


Name of the group Name property. Example: cn


Name of the group Type property. Example: cn


Name of the member attribute. Example: member


Accept of untrusted certificates if LDAP server uses SSL. Warning: We strongly advise against using this property. Better install untrusted certificates to JDK key store.


Set to true if LDAP connection uses SSL. Default: false


Value for the java.naming.factory.initial property. Default: com.sun.jndi.ldap.LdapCtxFactory


Value for the property. Default: simple


Indicates whether posix groups are used. If true, the connector will use a simple (unqualified) user id when querying for groups by group member instead of the full DN. Default: false


Allows to login anonymously without a password. Default: false

Warning: We strongly advise against using this property. You should configure your LDAP to use simple authentication without anonymous login.


If this property is set to true, then authorization checks are performed when querying for users or groups. Otherwise authorization checks are not performed when querying for users or groups. Default: true

Note: If you have a huge amount of LDAP users or groups we advise to set this property to false to improve the performance of the user and group query.


If this property is set to true, then ordering of the search results is enabled. Otherwise orderBy clauses in search queries are simply ignored. Default: false

Note: The support of search result ordering is not be implemented by every LDAP server. Make sure that your currently used LDAP Server implements the RFC 2891.

Throttle login attempts

In order to prevent security vulnerabilities we have a special mechanism for preventing subsequent unsuccessful login attempts. You can configure four properties so that this login mechanism is suitable for you:

  • loginMaxAttempts
  • loginDelayFactor
  • loginDelayMaxTime
  • loginDelayBase

These properties are configured in seconds. If you need to setup a maximum delay time of one minute, for example, you need to set 60, which represents the one minute in seconds. After a user fails to login for a maximum number of attempts, the user will be locked and will not be able to login again until an admin user unlocks the account.

Here is an example of the configuration:

    <!-- login configuration -->
    <property name="loginMaxAttempts" value="5" />
    <property name="loginDelayFactor" value="2" />
    <property name="loginDelayMaxTime" value="8" />
    <property name="loginDelayBase" value="1" />

The user has to wait baseTime * factor^(attempt-1) seconds, after an unsuccessful login attempt. In our case 2^(attempt) seconds, which means: a 1 second delay after the first attempt, 2 seconds after the 2nd attempt, 4 seconds, 8 seconds, 8 seconds, etc. (because loginDelayMaxTime time is set to 8 seconds) After the 5th attempt, if the user fails to login again, this user will be ‘locked’.

LDAP specifics

If you have a LDAP setup on your engine, you need to handle the throttling on the LDAP side. The login mechanism in your system will not be affected by the above properties.

On this Page: