Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-31870

Unable to use LDAP user credentials in build configuration

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Labels:
      None
    • Environment:
      Jenkins ver. 1.642.1 (LTS version)
      Credential plugin 1.24 (same with 1.18)
      Debian 8 64bits
      Tomcat 8.0.29
      OpenJDK 64-Bit Server VM (build 25.72-b05, mixed mode)
    • Similar Issues:

      Description

      Hello,

      We are using Jenkins with LDAP access control and Project-based Matrix Authorization Strategy.
      So user can defined User Credentials.

      However User Credentials are not listed in the list of credentials in my job, only system credentials are displayed (for instance when selecting GIT credentials to access Bitbucket).
      We tried User Global and Domain Credential with the same negative result.

      It is a fresh Jenkins install.
      The configuration looks OK, I am admin and I have all the rights activated at system and job level.
      I tested with various web browsers and got the same result.

      Some related unanswered questions I found:

        Attachments

          Issue Links

            Activity

            Hide
            stephenconnolly Stephen Connolly added a comment -

            This is more likely an issue in the SCM plugins not building the correct list for the drop-down

            Show
            stephenconnolly Stephen Connolly added a comment - This is more likely an issue in the SCM plugins not building the correct list for the drop-down
            Hide
            kuba_kuba Olivier added a comment -

            Ok, I also notice this issue in:

            • Credentials Parameter (don't know if it is a plugin or OOTB)
            • Multiple SCMs plugin (added into component list)
            Show
            kuba_kuba Olivier added a comment - Ok, I also notice this issue in: Credentials Parameter (don't know if it is a plugin or OOTB) Multiple SCMs plugin (added into component list)
            Hide
            kuba_kuba Olivier added a comment -

            Still occurs on LTS 1.642.1

            Show
            kuba_kuba Olivier added a comment - Still occurs on LTS 1.642.1
            Hide
            stephenconnolly Stephen Connolly added a comment -

            I will repeat, this is all down to how each individual SCM plugin has chosen to build the list of credentials.

            I do not see any facile way to handle this short of the Authorize Project Plugin moving its configuration from the Job Configuration screen and into a separate screen so that the Configure screen can know what authorization it will run as

            ikedam WDYT about Job/Authorization as a screen beside Job/Configure so that the configure screen will know the default authentication of the job?

            Show
            stephenconnolly Stephen Connolly added a comment - I will repeat, this is all down to how each individual SCM plugin has chosen to build the list of credentials. I do not see any facile way to handle this short of the Authorize Project Plugin moving its configuration from the Job Configuration screen and into a separate screen so that the Configure screen can know what authorization it will run as ikedam WDYT about Job/Authorization as a screen beside Job/Configure so that the configure screen will know the default authentication of the job?
            Hide
            ikedam ikedam added a comment -

            Stephen Connolly
            Let me see what you mean:

            • Separate the authorization configuration from the project configuration. This allows Jenkins to decide the authorization of builds during configuring projects.
            • When a plugin lists up credentials,
              public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Job project) {
                  Authentication auth = Tasks.getAuthenticationOf(project);
                  return new StandardUsernameListBoxModel().withEmptySelection().withAll(
                      CredentialsProvider.lookupCredentials(StandardUsernameCredentials.class, auth);
              }
              
            • Even if the authorization is changed after the project configuration is saved, it doesn't cause a security issue as the access to the credential is blocked at build time.

            That makes sense to me.

            Show
            ikedam ikedam added a comment - Stephen Connolly Let me see what you mean: Separate the authorization configuration from the project configuration. This allows Jenkins to decide the authorization of builds during configuring projects. When a plugin lists up credentials, public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Job project) { Authentication auth = Tasks.getAuthenticationOf(project); return new StandardUsernameListBoxModel().withEmptySelection().withAll( CredentialsProvider.lookupCredentials(StandardUsernameCredentials.class, auth); } Even if the authorization is changed after the project configuration is saved, it doesn't cause a security issue as the access to the credential is blocked at build time. That makes sense to me.
            Hide
            stephenconnolly Stephen Connolly added a comment -

            ikedam yep that's what I'm thinking... we'd just add a new side action called Authorization or Authentication or something like that. It would be a single page which would allow configuration of the build authorization. It could also simplify some of the configuration issues that we currently have as we can then lock down that screen so that a user can configure the build but not change the authorization (though we still have to keep the guards on config.xml submission and anyone letting somebody configure a job is basically giving them access to all the credentials that job can access, but for the use case of creating a special user that has the credentials available for the job I think that it is acceptable

            Show
            stephenconnolly Stephen Connolly added a comment - ikedam yep that's what I'm thinking... we'd just add a new side action called Authorization or Authentication or something like that. It would be a single page which would allow configuration of the build authorization. It could also simplify some of the configuration issues that we currently have as we can then lock down that screen so that a user can configure the build but not change the authorization (though we still have to keep the guards on config.xml submission and anyone letting somebody configure a job is basically giving them access to all the credentials that job can access, but for the use case of creating a special user that has the credentials available for the job I think that it is acceptable
            Hide
            ikedam ikedam added a comment -

            Created: JENKINS-35081 Separate authorization configuration page

            Show
            ikedam ikedam added a comment - Created: JENKINS-35081 Separate authorization configuration page
            Hide
            stephenconnolly Stephen Connolly added a comment -

            Really this is an issue in the individual plugins that provide the credentials drop down selector. They need to be build authentication aware. Currently they cannot be build authentication aware as that information is currently subject to change on the screen where they are being configured. When JENKINS-35081 is implemented the plugins would then be able to correctly infer the build authentication and then display the user credentials in those cases where the job runs as user.

            As such, this is not an issue with the credentials plugin rather at best this is a series of issues with credential consuming plugins.

            Marking this issue as not a defect on that basis

            Show
            stephenconnolly Stephen Connolly added a comment - Really this is an issue in the individual plugins that provide the credentials drop down selector. They need to be build authentication aware. Currently they cannot be build authentication aware as that information is currently subject to change on the screen where they are being configured. When JENKINS-35081 is implemented the plugins would then be able to correctly infer the build authentication and then display the user credentials in those cases where the job runs as user. As such, this is not an issue with the credentials plugin rather at best this is a series of issues with credential consuming plugins. Marking this issue as not a defect on that basis

              People

              • Assignee:
                Unassigned
                Reporter:
                kuba_kuba Olivier
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: