Test plan for "Check SSO status on SSH/API activity and direct user to SSO"
Test Plan
Introduction
This is a test plan for https://gitlab.com/gitlab-org/gitlab-ee/issues/9152
The feature implements SSO enforcement on SSH and API activity
Scope
- Includes SSH and API activity restrictions when SSO is enforced on SAML enabled group, its sub groups and projects
- Does not include web activity restrictions when SSO is enforced
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 "Projects", "Groups", "API" and "Git Access" 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 | |
---|---|---|---|---|
Groups | 2 | 1 | 2 | |
Project | 2 | 1 | ||
API | 1 | |||
Git Access | 1 |
Capabilities
-
Group is
- Intuitive
- When SSO is enforced and a user that not signed in with SSO tries to access the restricted group via API, it provides a clear message directing the user to SSO first.
- Secure
- When SSO is enforced, it does not allow any create, update and delete activity on the group or its resources (issues, labels etc) via API unless user has SSO'ed.
- When SSO is enforced, it allows read activity on the group and its resources via API without requiring the user to SSO if the group is public.
- Reliable
- When SSO enforcement is switched on for a top level group, any subgroups and projects within subgroups will also have SSO enforced.
- When SSO enforcement is switched on for a sub group, the parent group and any projects in the parent group will not have SSO enforced.
- Intuitive
-
Project is
- Intuitive
- When SSO is enforced and a user that not signed in with SSO tries to access a project in the restricted group via API or Git access (SSH and HTTP), it provides a clear message directing the user to SSO first.
- Secure
- When SSO is enforced, it does not allow any create, update and delete activity on a project in the restricted group via API or Git access (SSH and HTTP) unless user has signed in using SSO.
- When SSO is enforced, it allows read/clone activity on projects in the restricted group via API and Git access (SSH and HTTP) without requiring the user to SSO if the project is public.
- Intuitive
-
API is
- Secure
- When SSO is enforced, and the user has not logged in for the last 7 (or any threshold) or more days, API access should be denied prompting the user to SSO. This check should be performed with PAT, OAuth bearer token as well as when using session cookie.
- Secure
-
Git access is
- Secure
- When SSO is enforced, and the user has not logged in for the last 7 (or any threshold) or more days, git access via SSH or HTTP should be denied prompting the user to SSO.
- Secure
Automated e2e Tests
There should be an e2e QA test that would SSO using the web interface and perform Git operations (e.g. git push over SSH and HTTP)