| Authorize-project plugin has difficulties for its usage as it requires actual users to run builds as.
It can easily conflicts with policies of administrators:
- Administrators might don't want to use an actual user for managing authorizations of builds.
- E.g. Alice and Bob belongs to a DevOps team. They want to run a project with the authorization of DevOps, but not of Alice or Bob. Because it might cause problems when they quit the job.
- This can be resolved by defining a non-actual user used only to manage authorizations of builds.
- Administrator doesn't want to define or can't define non-actual users.
- It can be the case especialy when they use an external authentication system (such as Active Directory).
This can be resolved by introducing a feature to define non-actual users, just like build-in users such as ANONYMOUS and SYSTEM.
- They cannot be used to login Jenkins. (They don't have passwords)
- They have permissions. That is, AuthorizationStrategy should handle them as they handle actual users.
It might be a feature of authorize-project plugin, Jenkins core, or maybe a brand-new plugin. |
