You've primarily described https://issues.jenkins.io/browse/JENKINS-59109 which would add support for propagating user credentials from one build to another via the build step. The low level API is described here: https://github.com/jenkinsci/credentials-plugin/blob/master/docs/consumer.adoc#binding-user-supplied-credentials-parameters-to-builds which would be used in an implementation for JENKINS-59109 and any other plugins that wish to integrate this further. Ideally, this feature would offer the ability to specify which loaded credentials to propagate. The gist of the integration would propagate the user who bound each credential parameter so that downstream jobs still know which user corresponds to which credential binding for authorization purposes.

Hi Matt Sicker, here's what we deal with. First of all, we do use the Authorize Project Plugin with all jobs set to: Run as the user who triggered the build.

There's one "master" job with a credential parameter. Via that one, we can access the selected user-scope credential and all is nice and smooth.

The problem is, that this job triggers another builds via the build() step and those builds need the "master" build credential as well. And that's where we hit the wall, or mud at least, as there's an ugly way through, but the credentials parameter is not a big help in either of the workarounds we've figured out:

1. Use the credentials parameter in the downstream jobs and trigger them via Jenkins API and the user's auth token to pretend it was directly him/her who did it.
   This allows the authorize/credentials plugins to work properly and reach for the user's creds.
   The downside is that the triggering from the "master" job can't be done with the build() step, as that puts the master build as the main trigger cause, which IMHO kills the authorize plugin's Run as the user who triggered the build (even though the original user-triggered cause is also transitively visible)
   In one case we really reinvented the build() wheel to do that, and we made the users to save their auth tokens in their user creds and trigger the "master" build with it.
   For illustration the core looks like this:
   curl -sS -f -i -X POST "https://$JENKINS_HOSTNAME/job/$JOBNAME/buildWithParameters" --user "$USERNAME:$TOKEN" -data-urlencode "user_cred=$DESIRED_USER_CRED_ID"
   Sad things:

• rewritten build() in "user space"
• user has to manage one more credential than necessary (the auth token)
• the overall security of this is a bit questionable.

1. Pass the credential from the "master" build downstream as a Password parameter.
   That's pretty straightforward, we extract the desired credential in the "master" build and pass it as a string downstream via a password parameter. (recently we had fun with JENKINS-62305, but that's another story).
   Downsides:

• If the "master" build doesn't need the user credential, it has to access it anyways to pass it downstream.
• Duplicate parameters for the same thing - credential for those who run the downstream job directly, password for the "master" job.
• To at least hide this from the Build With Parameters screen, I've been omitting the password parameter declaration, but without it jenkins floods the logs with a security error about that it's being passed an undeclared parameter.

Ideally, the downstream job would be able to access the user creds in both cases:

• being triggered directly by the user
• being triggered by an upstream build triggered by the user.

If there's a way how to do that and have only one code / creds parameter for the downstream job and just passing the cred id from the upstream/"master" job, that would be a big relief. Right now, I don't see that option, but I'm not yet sure what the do next.

You also say

You can attach the actions directly via the low level API to simulate credential authorization by a user.

Can you elaborate on that a bit, toss pointers to some docs or examples if that's still relevant?

Thank you very much and sorry for the long post!

Vít Zikmund: are you using authorize project? If the build is running as the SYSTEM user, then it won't have access to other user's credentials as it's, you know, a different user.

The parameter API is the high level API. You can attach the actions directly via the low level API to simulate credential authorization by a user.

Hello Matt Sicker, I'm quite sure it is not the case. Your JENIKINS-58170 is nice, but it doesn't allow you to access the userscope credentials without them being supplied in a parameter.
I suppose Cyrille Le Clerc was trying to avoid using the build parameter entirely.

I personally don't see the security gain in this, especially if it's me, who's running the job, why wouldn't I want the job to access my user credentials? I know there's a possibility that if this got enabled, the job could guess and snoop any user's credential, but there could also be a way for the job to declare which credentials it's about to be accessing which the user would (until further change) accept only once and use it without selecting a credentials parameter each time s/he runs the build.

I actually found a way how to circumvent the limitation by creating an upstream job, that uses a user's jenkins API token to trigger the job with credentials via the Jenkins API (so the downstream build thinks it was directly run by the user, which is one of the requirements for the user creds to be read), but it required me/my peers to reinvent the whole build() logic with curl, and that just sucked. I'd still give an eternal praise to someone willing to reconsider these limitations to make them more user friendly.