Test plan for restricting personal access tokens to specific projects

Introduction

Currently, personal access api tokens do not have scoping at the project/group or functional level. This feature adds the ability to limit API access by personal access tokens to specific projects when creating a token.

Frontend: https://gitlab.com/gitlab-org/gitlab-ce/issues/47865 Backend: https://gitlab.com/gitlab-org/gitlab-ce/issues/20993

Scope

  • Includes testing the frontend changes for selecting projects accessible by the API personal access token.
  • Includes testing the API using the restricted personal access token.
  • Does not include testing access to groups or functional scope.

ACC Matrix

The matrix below identifies the Attributes, Components, and Capabilities relevant to the scope of this test plan.

Attributes (columns) are adverbs or adjectives that describe (at a high level) the qualities testing is meant to ensure Components have.

Components (rows) are nouns that define major parts of the product being tested.

Capabilities link Attributes and Components. They are what your product needs to do to make sure a Component fulfils an Attribute

This feature includes "Settings" and "API" functional area and so they included in the matrix.

For more information see the Google Testing Blog article about the 10 minute test plan and this wiki page from an open-source tool that implements the ACC model.

The numbers indicate the count of Capabilities at each intersection of Attribute and Component

Secure Responsive Intuitive Reliable
API 2 3
Settings 1 1 2

Capabilities

  • API

    • Reliable
      • It provides "authenticated user" access to the entire system, and full access only to specified projects in PAT. Link
      • It provides "authenticated user" access to groups, but prevent full access to groups when PAT has projects specified. Link
      • It continues to provide "authenticated user" access to the entire system when no project is specified.
    • Secure
      • User access levels are respected. When PAT has projects specified and if a user does not have full access to a project e.g. user is a Guest, or project is public, the API should reject write/delete changes.
      • When PAT has projects specified, access to the deploy_key API should be restricted.

  • Settings (Project dropdown) is

    • Intuitive
      • It's easy select all projects or one or multiple projects for access permissions.
      • It doesn't require unnecessary actions to save the change.
    • Responsive
      • The UI adjust appropriately to multiple screen sizes.
    • Secure
      • Any project that the user does not have access to should not show up in the dropdown.

Test Plan

Capabilities mentioned above can be used to guide the testing. Some cases needing special mention are indicated below. This list, however, should not be considered exhaustive and should only be used as a reference point for actual tests.

When adding new automated tests, please keep testing levels in mind.

Scenario 1: Dropdown list restrictions

  • Create a user who is a member of a few projects
  • Only public projects and the projects that the user is a member of should show up in the dropdown for setting access permission for the PAT.

Scenario 2: Maintainer user access

  • Create a user with maintainer access to a project.
  • Create PAT token for the project for this user.
  • The user should be able to edit/update the project via the API and the PAT token.

Scenario 3: Guest user access

  • Create a user with Guest access to a project.
  • Create PAT token for the project for this user.
  • The user should not be able to edit or delete the project via the API and the token.

Scenario 4: Project is public and user is not member

  • Create a user who is not a member of a public project A.
  • Create PAT for the project A for this user.
  • The user should not be able to edit or delete the project via the API and the token.

Scenario 5: User has maintainer access to a group

  • Create a user who has maintainer access to a group with multiple projects
  • Create PAT for this user for a particular project in this group.
  • The user should be able to update or delete the project assigned to PAT.
  • The user should not be able to update or delete other projects not assigned to PAT.
Edited by 🤖 GitLab Bot 🤖