POC: Use Access Tokens tied to a project and not to a user.

What does this MR do?

For: &637 (comment 358689613)

This is purely a POC and not production ready.

Idea: The idea of this MR is very limited in scope.

Specific problem we are trying to solve: With an access token tied to a project, and not to a user, hit the /housekeeping API for the project and trigger housekeeping on this project

Reason for choosing this endpoint for the POC:

• Simplicity: This endpoint does not care about project membership etc, which would have been hard to figure out with the actor being a token, and no user associated with it.

Implementation:

• Project tokens now have permissions in them (jsonb column), which can look like { housekeep_project: true, edit_project: false }, which helps us provide fine grained control to a project token.

• When an API request is made with project token, a new instance of ProjectTokenActor is created.

• With some new changes to DeclarativePolicy framework, it now figures out which policy class to check for permission based on both the actor (ProjectTokenActor instance, in this case) and the subject (which is the project).

• Based on this, ProjectPolicyForProjectTokenActor will be selected as the policy class and a check like can?(project_token_user, :housekeep_project, project) is made, which would return true or false based on what it has in its permissions hash.

Hence, there is no dependency on the user model and the permissions scope is also extensible.

Challenges:

• Any API that writes something to db, would be difficult to implement with this since we need a user to be associated as the "performer" of the action. Eg: In Audit Events, we record "who did the action", and this is always a user, and not a token.
• When finding members of the group etc, the current paradigm depends upon user and the method defined on the User model, which would be hard to implement in the PatUser model.

PS: If we decide to follow this strategy, we could still roll out this iteratively by using route_setting :authentication, project_token_allowed: true in specific endpoints. This helps us prevent making a lot of changes in a lot of places at once, so as to roll this out.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team