Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-2309

LDAP Plug-in for groups doesn't work when user DN's have special characters

    XMLWordPrintable

    Details

    • Type: Bug Report
    • Status: Closed
    • Priority: L3 - Default
    • Resolution: Fixed
    • Affects Version/s: 7.1.0
    • Fix Version/s: 7.2.0, 7.0.6, 7.1.3, 7.2.0-alpha3
    • Component/s: engine
    • Labels:
      None

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              smirnov Roman Smirnov
              Reporter:
              david.howe@auspost.com.au David Howe
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: