We are using Active Directory as our authentication backend. All of our directory entries have a "\" character in the DN like:

CN=Howe\, David,OU=XXXXX,OU=XXXXX,cn=XXXXX,dc=XXXXX,dc=com,dc=internal

The backslash is not an escape character, it's actually in the directory and on my site I am not in a position to change this.

When we use the Camunda LDAP plug-in, authorizations based on groups don't work - no groups are ever returned by the LdapIdentityProviderSession.findGroupByQueryCriteria method. I have debugged this and found that the group filter that is used doesn't match anything as it isn't escaping the "\" character contained in the DN. The filter that is generated is:

(&(objectclass=groupOfUniqueNames)(uniqueMember=CN=Howe\, David,OU=XXXXX,OU=XXXXX,cn=XXXXX,dc=XXXXX,dc=com,dc=internal))

when it should be:

(&(objectclass=groupOfUniqueNames)(uniqueMember=CN=Howe\5c, David,OU=XXXXX,OU=XXXXX,cn=XXXXX,dc=XXXXX,dc=com,dc=internal))

The list of escaped characters for filters can be found here https://www.owasp.org/index.php/Preventing_LDAP_Injection_in_Java.

I have attempted fixing this myself, but have run into a couple of problems:

1. The version of Apache DS being used in the test cases doesn't properly support special characters (see https://issues.apache.org/jira/browse/DIRSERVER-1442) making it difficult to write a unit test that proves the escaping is working
2. The LdapGroupQuery and LdapUserQueryImpl objects contain properties such as "firstName" and "firstNameLike". You can pass wildcards in both attributes and the query will work as expected. If you introduce blanket escaping of the filters in the LdapIdentityProviderSession class, then the wildcards get escaped as well and no longer function as wildcards. There are test cases (e.g. LdapUserQueryTest.testFilterByGroupIdAndEmailLike) that don't use the "userEmailLike" property to do a wildcard search.

My initial thought was to escape the properties that don't contain like (e.g. "firstName") and not escape the properties that do contain like (e.g. "firstNameLike") but this didn't seem like a full solution, and changes existing functionality.

To get around my immediate problem, escaping the user DN in LdapIdentityProviderSession.getGroupSearchFilter would suffice:

if (query.getUserId() != null) {
addFilter(ldapConfiguration.getGroupMemberAttribute(),
escapeLDAPSearchFilter(getDnForUser(query.getUserId())), search);
}

Where escapeLDAPSearchFilter is taken from https://www.owasp.org/index.php/Preventing_LDAP_Injection_in_Java.