Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-1860

Retrieve only the necessary attributes when searching for LDAP users and groups

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Fixed
    • 2.6
    • Directory - LDAP
    • None

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Currently Crowd makes a query for all the attributes on a given entity: role, group or user. This results in a very large dataset being returned for all searches, regardless of purpose.

      At a minimum, we should only request attributes which are used by Crowd: the name, description and member attributes for groups and roles, and all the mapped attributes for users.

      Even better would be to retrieve only the membership attributes when searching for memberships, only the group attributes when looking up groups, and so on.

      The minimum requirement is quite easy to implement, and I'll attach a simple (completely untested) patch that I'd like to see tested in the future. The second option would be harder, requiring some redesign of the SpringLDAPConnector, which currently has only has one place where SearchControls objects are constructed for all LDAP searches.

        1. CONF-22326-patch.zip-4.3.2
          28 kB
        2. CWD-1860_naive_and_untested_implementation.patch
          2 kB
        3. CWD-1860_naive_and_untested_implementation.patch
          2 kB
        4. CWD-1860_naive_and_untested_implementation.patch
          2 kB

            [CWD-1860] Retrieve only the necessary attributes when searching for LDAP users and groups

            Matt Ryall added a comment -

            Note: this patch works only for Active Directory. It has hard-coded attribute names in it that will break in unusual ways on other servers.

            Matt Ryall added a comment - Note: this patch works only for Active Directory. It has hard-coded attribute names in it that will break in unusual ways on other servers.

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - - edited

            I have attached patch.zip-4.3.2 for versions 4.3.2 - 4.3.7 of Confluence, and any Atlassian app with version 1.5.3 of Embedded Crowd (check with Support if you're unsure). Please refer to the installation instructions on how to install this patch.

            The subdirectories for the class file are <confluence-installation-directory>/confluence/WEB-INF/classes/com/atlassian/crowd/directory. Please create these folders if they don't already exist. You need to remove the "-4.3.2" from the class file names before copying them.

            NB: This patch is not formally tested, so please ensure that you apply this to a test Confluence instance and test it thoroughly before applying it to your production Confluence.

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - - edited I have attached patch.zip-4.3.2 for versions 4.3.2 - 4.3.7 of Confluence, and any Atlassian app with version 1.5.3 of Embedded Crowd (check with Support if you're unsure). Please refer to the installation instructions on how to install this patch. The subdirectories for the class file are <confluence-installation-directory>/confluence/WEB-INF/classes/com/atlassian/crowd/directory . Please create these folders if they don't already exist. You need to remove the "-4.3.2" from the class file names before copying them. NB: This patch is not formally tested, so please ensure that you apply this to a test Confluence instance and test it thoroughly before applying it to your production Confluence.

            Craig Solinski added a comment -

            Hi, I have not seen activity on this and I'm sure it affects all large institutions negatively. We cannot upgrade without a resolution in place. We are currently using a patch for Confluence 3.5.16 - crowd-ldap-2.3.2.jar and crowd-persistence-2.3.2.jar else cannot even operate. We have heard these jars will not work in 4.x.
            Please reply so I can inform management.

            Thanks,
            Craig

            Craig Solinski added a comment - Hi, I have not seen activity on this and I'm sure it affects all large institutions negatively. We cannot upgrade without a resolution in place. We are currently using a patch for Confluence 3.5.16 - crowd-ldap-2.3.2.jar and crowd-persistence-2.3.2.jar else cannot even operate. We have heard these jars will not work in 4.x. Please reply so I can inform management. Thanks, Craig

            Mark Lassau (Inactive) added a comment -

            Note that if we want to eventually detect renames coming from an LDAP directory then this is another reason to be able to explicitly name LDAP entity attributes to be fetched.
            The "entryUUID" attribute on OpenLDAP is not returned with the default attributes.

            Mark Lassau (Inactive) added a comment - Note that if we want to eventually detect renames coming from an LDAP directory then this is another reason to be able to explicitly name LDAP entity attributes to be fetched. The "entryUUID" attribute on OpenLDAP is not returned with the default attributes.

            Justin Koke added a comment -

            The patch is very fragile, and still the list of attributes is incomplete, due to some of the Tombstone user attributes required for AD, and I am sure there might be others.

            The other issue is we need to make sure that LDAP servers will behave correctly with this list, and not try to retrieve attributes that may or may not exist from this list (this is mostly a random though, but we need to test).

            Justin Koke added a comment - The patch is very fragile, and still the list of attributes is incomplete, due to some of the Tombstone user attributes required for AD, and I am sure there might be others. The other issue is we need to make sure that LDAP servers will behave correctly with this list, and not try to retrieve attributes that may or may not exist from this list (this is mostly a random though, but we need to test).

            Matt Ryall added a comment -

            The attached patch won't work due to the requirements of CustomAttributeMappers. These need access to other unspecified attributes in the LDAP search results, and don't currently have any way of declaring their required attributes.

            I suggest we change the CustomAttributeMapper API to require specifying which attributes (as a String[]) are needed by each mapper.

            Matt Ryall added a comment - The attached patch won't work due to the requirements of CustomAttributeMappers. These need access to other unspecified attributes in the LDAP search results, and don't currently have any way of declaring their required attributes. I suggest we change the CustomAttributeMapper API to require specifying which attributes (as a String[]) are needed by each mapper.

            Justin Koke added a comment -

            Slightly updated patch that passes the attributes through a Set as a quick way to stop duplicate attributes

            Justin Koke added a comment - Slightly updated patch that passes the attributes through a Set as a quick way to stop duplicate attributes

              jwalton joe
              matt@atlassian.com Matt Ryall
              Votes:
              3 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: