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

Created: JENKINS-35081 Separate authorization configuration page

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

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?

Still occurs on LTS 1.642.1

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)

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