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

Research possible support of a dynamic LDAP group

    Details

    • Type: Task
    • Status: Closed
    • Priority: L3 - Default
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.8.0, 7.8.0-alpha2
    • Component/s: engine
    • Labels:

      Description

      AT:

      • using the LDAP plugin, I can get the users of a dynamic group

        Activity

        Hide
        svetlana.dorokhova Svetlana Dorokhova added a comment - - edited

        Results of research

        Members of dynamic groups are defined not via member attribute, but via memberURL, which contains the search query to list the group members.

        Nevertheless, when we request the group via ldapsearch, it contains member attributes. E.g.:

        The problem is that these member attributes are populated dynamically, which means that we can not use them in search queries directly. E.g. this query returns no results:

        baseDN: dc=acme,dc=org
        filter: 
        (&
            (objectClass=groupOfURLs)
            (member=cn=2005,ou=people,dc=acme,dc=org)
        )
        

        ,
        but in case of normal (not dynamic) groups it would have returned one group listed above.

        As a result our LdapIdentityProviderSession#getGroupsOfUser does not work correctly. -> IdentityService#getCurrentAuthentication() contains no groups ever, which affects the behaviour of user/group dependent code.

        Possible solutions:

        1. Customer can extend our Ldap plugin overriding at least LdapIdentityProviderSession#getGroupsOfUser method. (Further analysis needed to find out what other parts of plugin could be affected.) It seems that the specific customer - author of SUPPORT ticket - has group attribute defined for each user. In theory it can be used to search for user groups, but this is not a standardized approach -> does not make sense to be implement on our side.
        2. We could try to support dynamic groups in general. E.g. when useDynamicGroups configuration option is switched on, we avoid member attribute and rely only on memberURL defined for group. This though may have a bad impact on performance, as we would need to iterate over all groups and resolve the members list for each of them.
        3. We could extend our Ldap plugin by making search queries for "list of user groups" and "list of group users" configurable. This would be a more generic approach, but this is just a rough proposal. If we seriously considering to go this way, further research must be performed, before we promise smth.
        Show
        svetlana.dorokhova Svetlana Dorokhova added a comment - - edited Results of research Members of dynamic groups are defined not via member attribute, but via memberURL , which contains the search query to list the group members. Nevertheless, when we request the group via ldapsearch , it contains member attributes. E.g.: The problem is that these member attributes are populated dynamically, which means that we can not use them in search queries directly. E.g. this query returns no results: baseDN: dc=acme,dc=org filter: (& (objectClass=groupOfURLs) (member=cn=2005,ou=people,dc=acme,dc=org) ) , but in case of normal (not dynamic) groups it would have returned one group listed above. As a result our LdapIdentityProviderSession#getGroupsOfUser does not work correctly. -> IdentityService#getCurrentAuthentication() contains no groups ever, which affects the behaviour of user/group dependent code. Possible solutions: Customer can extend our Ldap plugin overriding at least LdapIdentityProviderSession#getGroupsOfUser method. (Further analysis needed to find out what other parts of plugin could be affected.) It seems that the specific customer - author of SUPPORT ticket - has group attribute defined for each user. In theory it can be used to search for user groups, but this is not a standardized approach -> does not make sense to be implement on our side. We could try to support dynamic groups in general. E.g. when useDynamicGroups configuration option is switched on, we avoid member attribute and rely only on memberURL defined for group. This though may have a bad impact on performance, as we would need to iterate over all groups and resolve the members list for each of them. We could extend our Ldap plugin by making search queries for "list of user groups" and "list of group users" configurable. This would be a more generic approach, but this is just a rough proposal. If we seriously considering to go this way, further research must be performed, before we promise smth.
        Hide
        svetlana.dorokhova Svetlana Dorokhova added a comment - - edited

        BTW there is (or was?) a draft specification for Dynamic Groups: https://tools.ietf.org/html/draft-haripriya-dynamicgroup-02

        The interesting thing is that it is declared that search by member attribute must work in similar way for both dynamic and normal groups (at least I understood it like this), which is not true for OpenLdap implementation.

        Here it is:

        6.1.3. 'Is Member Of' functionality

        <...>

        Likewise, a search operation that contains an equalityMatch or
        presence filter, naming the member or uniqueMember attribute as the
        attribute (such as (member= cn=bob,ou=finance,o=myorg), or
        (member=*)), will cause the server to evaluate this filter against
        the rules given in Section 4.2.1.3 in the event that the search is
        performed on a dynamic group object. As of this writing, no other
        matching rules exist for the distinguished name syntax, thus no
        requirements beyond equalityMatch are given here.

        Show
        svetlana.dorokhova Svetlana Dorokhova added a comment - - edited BTW there is (or was?) a draft specification for Dynamic Groups: https://tools.ietf.org/html/draft-haripriya-dynamicgroup-02 The interesting thing is that it is declared that search by member attribute must work in similar way for both dynamic and normal groups (at least I understood it like this), which is not true for OpenLdap implementation. Here it is: 6.1.3. 'Is Member Of' functionality <...> Likewise, a search operation that contains an equalityMatch or presence filter, naming the member or uniqueMember attribute as the attribute (such as (member= cn=bob,ou=finance,o=myorg), or (member=*)), will cause the server to evaluate this filter against the rules given in Section 4.2.1.3 in the event that the search is performed on a dynamic group object. As of this writing, no other matching rules exist for the distinguished name syntax, thus no requirements beyond equalityMatch are given here.

          People

          • Assignee:
            roman.smirnov Smirnov Roman
            Reporter:
            philipp.ossler Philipp Ossler
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: