Open RPCMoritz opened 2 weeks ago
Technically, it wouldn't be that hard and this would be easier for non-interactive cases.
It raises a number of questions regarding user and access management in Jenkins and in the plugin.
Indeed, as OIDC wouldn't be there to provision permissions, a secondary permission-provisioning approach would need to be put in place. I am thinking of a SCIM(-like?) API, authenticated/authorized with an admin token, to add users and their access rights.
This would also need a way to combine the user permissions from these two separate sources.
Thinking a bit more about it, I don't see how it could work unless the access token is a JWT or an introspect token endpoint is available.
I would expect either of those to be present in most implementations, but yes, that would add the corresponding handling of those "data sources" to the scope.
What feature do you want to see added?
A more natural way to consume API endpoints, would be by using oauth client credential flow-based authentication credentials. These should be possible to be validated, in the same way as the session credentials provided via OIDC.
The currently designed solution, using API token has some drawbacks, when designing for independent service identities over personal access.
Is this something that could be scoped into the features of this plugin?
Upstream changes
No response
Are you interested in contributing this feature?
I'll have to review the current code-base first, but we have a pretty large Jenkins fleet, so we might be able to contribute, if it sounds like a reasonable option.