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

Unable to use LDAP user credentials in build configuration

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Not A Defect
    • None
    • 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)

    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

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

            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
            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)
            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)
            kuba_kuba Olivier added a comment -

            Still occurs on LTS 1.642.1

            kuba_kuba Olivier added a comment - Still occurs on LTS 1.642.1

            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?

            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?
            ikedam ikedam added a comment -

            stephenconnolly
            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.

            ikedam ikedam added a comment - stephenconnolly 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.

            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

            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
            ikedam ikedam added a comment -

            Created: JENKINS-35081 Separate authorization configuration page

            ikedam ikedam added a comment - Created: JENKINS-35081 Separate authorization configuration page

            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

            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

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

              Dates

                Created:
                Updated:
                Resolved: