authorize-project-plugin have following issues for its design.

• Authentications of the project during configuration and after configuration may change.
  • This makes it difficult for other plugins behave depending on authentications of projects.
• The way to reject unauthenticated configurations is unstable.
  • authorize-project plugin should reject user A configure a project when the project is configured as user B.
  • The current implementation raises exception when saving unauthenticated configurfation.
• Difficult to configure permissions of builds.
  • What users really want to do is to configure permissions of builds.
    • This is why I named it "authorize-project".
  • QueueItemAuthenticator is designed to return Authentication, which can be considered a user.
  • And then, the current design of authorize-project is to configure builds run as a specific user.
    • This might mean "authenticate-project" was more appropreate for the plugin name.
  • This causes following difficulties:
    • There can be cases that administrators don't want to bind a project to an actual specific user.
      • Alice and Bob belongs to DevOps group. They want run builds of a project as the permission of DevOps, but don't to run as Alice or Bob as they both want configure the project.
    • There can be cases that administrators cannot define a new user for build authentications. E.g. Jenkins is configured to use an external user dictionary (e.g. Active Directory) and the administrator of Jenkins doesn't administer that directory.