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.