We have integrated Camunda 7.16 with our company’s LDAP server. However for some reasons, its behaving weirdly. We have created several groups and users in LDAP and the link between users and groups is established in LDAP it self.
However, for certain groups, Camunda is taking too long to fetch users, and after taking a longtime it ends up showing only 1 user = GDldap Sync-Reader . This user does not even exists in our LDAP.
So from where is Camunda, able to fetch this user under certain groups ? See the screenshot below, when the group details are opened in Camunda admin: -
Interesting thing is, it is showing the First name + Last name combination as the user id which is not the case usually, as in our LDAP we have user ids that do not contain white space and is not a concatenation of First name and last name.
If I try to get more details of this user by clicking on it, the page takes forever to load and does not load anything. PFA the screenshot
Also, I would like to know, how does the TaskQuery.taskCandidateUser() work ? … currently it is the cause of performance issue in our setup as it takes a lot of time to check and fetch details from LDAP. Can we provide our custom logic that will execute when this method is invoked in the code ? If yes then how to do that ? Also, which loggers and how should we enable them to see, what requests Camunda is sending to the LDAP and responses its getting from LDAP ?
It would be really very great if anybody can help in this regard ?
Hi, I am a coworker of Omkar and responsible for the LDAP server in our organization. First of all, it turned out the the GDldap Sync-Reader is a technical account in a special subtree. It is not member of any group. Why it shows up in the Camunda searches is unclear.
As for the attributes, in our LDAP, “cn” is the username i.e. something like “puescheo”, “uid” is a numeric value like 74706 an “sn” and “givenname” contain last name and first name respecitively.
When you define your base LDAP tree, user will be appeared in search for any ldapsearch. It does not restrict whether user is belong to particular group or not. This will be checked during authorization phase only.
Normally givenname does not have firstname and lastname in any ldap configuration. As per your reply, given name is retrieved from ldap, which shows first name and last name in the UI.
Would you mind sharing which LDAP implementation are you using it?
Meanwhile can someboday help me with the development related queries in my question: -
Also, I would like to know, how does the TaskQuery.taskCandidateUser() work ? … currently it is the cause of performance issue in our setup as it takes a lot of time to check and fetch details from LDAP. Can we provide our custom logic that will execute when this method is invoked in the code ? If yes then how to do that ? Also, which loggers and how should we enable them to see, what requests Camunda is sending to the LDAP and responses its getting from LDAP ?
1.Is this Shared or embedded Engine? → Sorry i did not get this. We are using Camunda 7.16 with Apache Tomcat inside it. We have modified its server.xml by configuring the LDAP settings as shown in the screenshot above.
2. What’s your LDAP server version? → @olfp42 can you please respond to this ?
3. Is this your Dev or Production Environment? → Camunda env is DEV env, but its connected to organization’s PROD LDAP
Apologies to tag you all, but not aware if anyone can help and hence I have tagged the people I know. I have some queries related to the camunda APIs to work with LDAP (the one i have mentioend in my original post): -
Also, I would like to know, how does the TaskQuery.taskCandidateUser() work ? … currently it is the cause of performance issue in our setup as it takes a lot of time to check and fetch details from LDAP. Can we provide our custom logic that will execute when this method is invoked in the code ? If yes then how to do that ? Also, which loggers and how should we enable them to see, what requests Camunda is sending to the LDAP and responses its getting from LDAP ?
Difficult to spot a error in your configs. Here is how i debugged similar issue when i was configuring camunda ldap plugin in a spring boot project.
Started an openldap instances with a schema. You can refer my repo GitHub - amardeep2006/camunda-springboot-ldap-integration: Securing Camunda webapps and REST API via LDAP users
You should look at openldap example as my image also bootstraps a basic minimal schema as well. You can adjust schema as per your need.
Point camunda towards ldap .
Enable the query logs in openldap image. I donot remember the exact config for this but probably LDAP_LOGLEVEL may be useful. Look at the docs for ldap image here . it has tons of env variable configs for openldap docker image. bitnami/openldap - Docker Image | Docker Hub
This may show the ldap queries fired by camunda in ldap logs and may give some ideas.
If you can enable logs level in your existing ldap that will be wonderful.
The highlighted blurred boxes are each camunda process applications (war files :- each war file having its own processes.xml and the BPMN(s) and DMN(s) ) that we have developed.
Based on the link that you have provided, I think, our client application should request data using Camunda REST API but as HAL… did I get it right ? So the configuration mentioned in the link will work only if the client application requests data from the API as HAL ?
Because, the implementation to fetch the tasks, users and groups etc., we have in implemented in one of the camunda process application that is deployed in webapps. So the implementation involves invoking the native Camunda APIs like TaskQuery.taskCandidateUser()… will the caching approach still work and how to use it as HAL ? (HAL media type set in accept header of HTTP request)
Because, if I had to use the APIs as HAL, in the rest client I can mention media type as “application/hal+json” … but how do I configure this for native APIs like TaskQuery.taskCandidateUser() ?
Yes, enabling the cache applies only to REST API communication. It seems you are experiencing a performance issue when connecting to your LDAP, which is likely unrelated to Camunda. I recommend testing the connection to your LDAP using a tool like Apache Directory Studio installed on the process engine server.
