First of all, thank you for thinking about what the project needs, rather than focusing narrowly on fixing problems with an existing design.
On Tue, Aug 27, 2019 at 4:16 AM ikedam <[email protected]> wrote: > I believe users want to define permissions not bound to actual specific users > such as those in LDAP, or Active Directory. But Jenkins doesn’t provide > mechanisms for authentications not bound to specific users, like sevice > accounts in Google Cloud Platform. Right, this is a very longstanding need. It is usually tracked alongside security realm multiplexing as JENKINS-15063, though the service account concept is a more limited feature that might be better implemented directly. > I expect QueueItemAuthenticator can be replaced with other permission > mechanisms not bound to specific users, like permissions between jobs I might not phrase it as “permissions” because that might be taken to mean that such a system must be based on Jenkins’ `ACL` + `Permission` + `Authentication`. You _could_ pick a design based on service accounts configured in the `AuthorizationStrategy`, but there are alternative choices. For reference, CloudBees Core includes a different design to solve a subset of this problem (what `QueueItemAuthenticator` would let you control in the case of `Job.BUILD` permission): https://go.cloudbees.com/docs/cloudbees-core/cloud-admin-guide/trigger-restrictions/ -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0yNdcsCa_1nxqOw-CHoSOZaUK2BA-%3DhKDV-kuMQHUobg%40mail.gmail.com.
