• Icon: Suggestion Suggestion
    • Resolution: Won't Fix
    • None
    • Directory - LDAP
    • None
    • 3
    • 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.

      Crowd binds to for instance OpenLDAP with a preconfigured username and password, which implies that all use of the same directory configuration has the same rights in the LDAP directory. (This could be worked around by configuring multiple connectors to the same backend with different users, but this would soon be a messy configuration.)

      It would be really useful to enable Crowd to use anonymous bind to the LDAP directory with the end users own credentials, thus performing operations that the user has right to do.

      For instance: If we only want a few users to be able to add new users to the directory, this can be set in OpenLDAP with ACLs. When I log into Crowd it should be, in my opinion, the LDAP directory that authorizes me to perform write operations.

      Storing a root/manager-password for the directory in Crowd is the only way for some directories/backends, but for more flexible backends like OpenLDAP it should not be necessary to do this. One can argue that it increases security if no username/passwords are stored in Crowd at all, and since Crowd is an important component in a security framework this should be supported.

            [CWD-585] Support for user-specific bind to LDAP

            shihab added a comment -

            Applications connected to Crowd request access to userbase data in the context of the application, not a user. So for example, when JIRA needs to search for users, this search is conducted in Crowd against all directories that JIRA is mapped to. If we were to pass a user parameter along from JIRA to Crowd for all API methods then it would be impossible to efficiently cache on the client side as each query would be specific to a particular user.

            shihab added a comment - Applications connected to Crowd request access to userbase data in the context of the application, not a user. So for example, when JIRA needs to search for users, this search is conducted in Crowd against all directories that JIRA is mapped to. If we were to pass a user parameter along from JIRA to Crowd for all API methods then it would be impossible to efficiently cache on the client side as each query would be specific to a particular user.

            DonnaA added a comment -

            The ability to toggle this on a per-directory basis would make sense. We could optionally allow a directory to use a principal's credentials rather than connector credentials for items like updating passwords or modifying group memberships.

            DonnaA added a comment - The ability to toggle this on a per-directory basis would make sense. We could optionally allow a directory to use a principal's credentials rather than connector credentials for items like updating passwords or modifying group memberships.

              justen.stepka@atlassian.com Justen Stepka [Atlassian]
              865f90db8294 Lars Preben Sørsdahl
              Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: