POC: Use Access Tokens tied to a project and not to a user.
What does this MR do?
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 thesubject
(which is theproject
). -
Based on this,
ProjectPolicyForProjectTokenActor
will be selected as the policy class and a check likecan?(project_token_user, :housekeep_project, project)
is made, which would returntrue
orfalse
based on what it has in itspermissions
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 theUser
model, which would be hard to implement in thePatUser
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