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
Example:
User demoUser = processEngine.getIdentityService()
.createUserQuery()
.userId("demo")
.singleResult();
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:
- org.camunda.bpm.engine.impl.identity.ReadOnlyIdentityProvider
- org.camunda.bpm.engine.impl.identity.WritableIdentityProvider
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.
<dependency>
<groupId>org.camunda.bpm.identity</groupId>
<artifactId>camunda-identity-ldap</artifactId>
</dependency>
Activate the LDAP Plugin
The following is an example of how to configure the LDAP Identity Provider Plugin using Spring XML:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="processEngineConfiguration" class="org.camunda.bpm.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration">
...
<property name="processEnginePlugins">
<list>
<ref bean="ldapIdentityProviderPlugin" />
</list>
</property>
</bean>
<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" />
</bean>
</beans>
The following is an example of how to configure the LDAP Identity Provider Plugin in bpm-platform.xml/processes.xml:
<process-engine name="default">
<job-acquisition>default</job-acquisition>
<configuration>org.camunda.bpm.engine.impl.cfg.StandaloneProcessEngineConfiguration</configuration>
<datasource>java:jdbc/ProcessEngine</datasource>
<properties>...</properties>
<plugins>
<plugin>
<class>org.camunda.bpm.identity.impl.ldap.plugin.LdapIdentityProviderPlugin</class>
<properties>
<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>
</properties>
</plugin>
</plugins>
</process-engine>
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.
Multi-Tenancy
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 |
baseDn |
The base DN: Identifies the root of the LDAP directory. Is appended to all DN names composed for searching for users or groups. Example: |
userSearchBase |
Identifies the node in the LDAP tree under which the plugin should search for users. Must be relative to Example: |
userSearchFilter |
LDAP query string used when searching for users. Example: |
userIdAttribute |
Name of the user Id property. Example: |
userFirstnameAttribute |
Name of the firstname property. Example: |
userLastnameAttribute |
Name of the lastname property. Example: |
userEmailAttribute |
Name of the email property. Example: |
userPasswordAttribute |
Name of the password property. Example: |
groupSearchBase |
Identifies the node in the LDAP tree under which the plugin should search for groups. Must be relative to Example: |
groupSearchFilter |
LDAP query string used when searching for groups. Example: |
groupIdAttribute |
Name of the group Id property. Example: |
groupNameAttribute |
Name of the group Name property. Example: |
groupTypeAttribute |
Name of the group Type property. Example: |
groupMemberAttribute |
Name of the member attribute. Example: |
acceptUntrustedCertificates |
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. |
useSsl |
Set to true if LDAP connection uses SSL. Default: |
initialContextFactory |
Value for the |
securityAuthentication |
Value for the |
usePosixGroups |
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: |
allowAnonymousLogin |
Allows to login anonymously without a password. Default: Warning: We strongly advise against using this property. You should configure your LDAP to use simple authentication without anonymous login. |
authorizationCheckEnabled |
If this property is set to
Note: If you have a huge amount of LDAP users or groups we advise to set this property to |
sortControlSupported |
If this property is set to 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
A mechanism exists for preventing subsequent unsuccessful login attempts.The essence of it is that the user is not able to log in for a specific amount of time after unsuccessful login attempts. The amount of time is calculated after each attempt but it is limited by maximum delay time. After a predefined number of unsuccessful attempts, the user will be locked and only an administrator has permissions to unlock them.
The mechanism is configurable with the following properties and respective default values.
loginMaxAttempts=10
loginDelayFactor=2
loginDelayMaxTime=60
loginDelayBase=3
For more information, please check the process engine’s login properties section.
Calculation of the delay is done via the formula: baseTime * factor^(attempt-1)
.
The behaviour with the default configuration will be:
3 seconds delay after the first unsuccessful attempt, 6 seconds after the 2nd attempt, 12 seconds, 24 seconds, 48 seconds, 60 seconds, 60 seconds, etc. After the 10th attempt, if the user fails to login again, the 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.