IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.

    • 4
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      attached is some code to do LDAP authentication in JIRA in an interesting way.

      the idea is to use LDAP "lazily". Here's the text of a message to jira-user that describes the basic idea:

      ====================
      the way we chose to manage this was to leave "external user
      management" OFF, and to write a custom "credentials provider" that
      worked the way we wanted.

      it was not completely simple, because of how the osuser framework
      works, but we managed to more or less get it working the way we
      wanted.

      our LDAP credentials provider contains a reference to an "underlying"
      OfBiz (standard) credentials provider. it works by first
      authenticating the user against LDAP, then:

      if the authentication was successful
      if the user exists in the underlying provider
      succeed
      else
      create the user in the underlying provider, using info from LDAP,
      and succeed
      else
      if the user exists in the underlying provider
      if we can authenticate the user in the underlying provider
      succeed
      else
      fail

      this means that users are created in JIRA's database on-demand. it
      also means that if our LDAP goes down, people with existing JIRA
      accounts can still login to JIRA, using their passwords in the
      underlying provider. which is nice since we use JIRA (among other
      things) to report system/network problems with things like LDAP
      servers.

      one problem (and here my memory fails a bit, so I might get some
      details wrong) is that we still can't use JIRA's Add User feature
      directly. There should be no reason why this wouldn't work, but a
      quirk in the OSUser framework prevents it. Basically (again, IIRC)
      there is a "handles" method that providers need to implement, and
      this method is called with the username before any other methods
      (authenticate, create, etc.) are called. When adding a user (this is
      assuming we're using the same uid as in LDAP) the framework first
      checks if our provider handles that UID. since it does (the uid
      already exists in LDAP) it doesn't make sense to create it, so the
      Add User fails, even though the user doesn't exist in the underlying
      provider.

      this isn't a big deal, usually, since people can just login on their
      own and everything will be created for them. the only problem is if
      you (the admin) wanted to create a user and add them to some groups.

      to get around this, we also wrote a "backdoor" action, accessible
      from the web but not part of JIRA's main interface, that can
      manipulate the ofbiz database more or less directly. we use this if
      we need to add new users to specific groups.

      ====================

            Loading...
            IMPORTANT: JAC is a Public system and anyone on the internet will be able to view the data in the created JAC tickets. Please don’t include Customer or Sensitive data in the JAC ticket.

              • 4
              • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

                attached is some code to do LDAP authentication in JIRA in an interesting way.

                the idea is to use LDAP "lazily". Here's the text of a message to jira-user that describes the basic idea:

                ====================
                the way we chose to manage this was to leave "external user
                management" OFF, and to write a custom "credentials provider" that
                worked the way we wanted.

                it was not completely simple, because of how the osuser framework
                works, but we managed to more or less get it working the way we
                wanted.

                our LDAP credentials provider contains a reference to an "underlying"
                OfBiz (standard) credentials provider. it works by first
                authenticating the user against LDAP, then:

                if the authentication was successful
                if the user exists in the underlying provider
                succeed
                else
                create the user in the underlying provider, using info from LDAP,
                and succeed
                else
                if the user exists in the underlying provider
                if we can authenticate the user in the underlying provider
                succeed
                else
                fail

                this means that users are created in JIRA's database on-demand. it
                also means that if our LDAP goes down, people with existing JIRA
                accounts can still login to JIRA, using their passwords in the
                underlying provider. which is nice since we use JIRA (among other
                things) to report system/network problems with things like LDAP
                servers.

                one problem (and here my memory fails a bit, so I might get some
                details wrong) is that we still can't use JIRA's Add User feature
                directly. There should be no reason why this wouldn't work, but a
                quirk in the OSUser framework prevents it. Basically (again, IIRC)
                there is a "handles" method that providers need to implement, and
                this method is called with the username before any other methods
                (authenticate, create, etc.) are called. When adding a user (this is
                assuming we're using the same uid as in LDAP) the framework first
                checks if our provider handles that UID. since it does (the uid
                already exists in LDAP) it doesn't make sense to create it, so the
                Add User fails, even though the user doesn't exist in the underlying
                provider.

                this isn't a big deal, usually, since people can just login on their
                own and everything will be created for them. the only problem is if
                you (the admin) wanted to create a user and add them to some groups.

                to get around this, we also wrote a "backdoor" action, accessible
                from the web but not part of JIRA's main interface, that can
                manipulate the ofbiz database more or less directly. we use this if
                we need to add new users to specific groups.

                ====================

                        Unassigned Unassigned
                        28a9e6a89167 joe dane
                        Votes:
                        2 Vote for this issue
                        Watchers:
                        6 Start watching this issue

                          Created:
                          Updated:
                          Resolved:

                            Unassigned Unassigned
                            28a9e6a89167 joe dane
                            Votes:
                            2 Vote for this issue
                            Watchers:
                            6 Start watching this issue

                              Created:
                              Updated:
                              Resolved: