The v3 token API should account for different scopes

Bug #1750676 reported by Lance Bragstad on 2018-02-20
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
High
Unassigned

Bug Description

Keystone implemented scope_types for oslo.policy RuleDefault objects in the Queens release. In order to take full advantage of scope_types, keystone is going to have to evolve policy enforcement checks in the user API. This is documented in each patch with FIXMEs [0].

The following acceptance criteria describes how the v3 authentication API should behave with tokens from multiple scopes:

HEAD /v3/auth/tokens

- Someone with a system role assignment that passes the check string should be able to check any token issued from a deployment's keystone (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to check tokens for users that are members of the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to check tokens that are scoped to the project they administer (project-scoped)
- Someone with a token should be able to validate the token with itself

GET /v3/auth/tokens

- Someone with a system role assignment that passes the check string should be able to validate any token issued from a deployment's keystone (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to validate tokens for users that are members of the domain they administer (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to validate tokens that are scoped to the project they administer (project-scoped)
- Someone with a token should be able to validate the token with itself

DELETE /v3/auth/tokens

- Someone with a system role assignment that passes the check string should be able to revoke any token issued by the deployment's keystone (system-scoped)
- Someone with a domain role assignment that passes the check string should only be able to revoke tokens scoped to the domain they administer, or projects within that domain (domain-scoped)
- Someone with a project role assignment that passes the check string should only be able to revoke tokens scoped to the project they administer (project-scoped)
- Any user should be able to invalidate their own token by setting it as the X-Auth-Header and the X-Subject-Header

[0] https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/token.py#L21-L32

Colleen Murphy (krinkle) on 2018-09-19
tags: added: system-scope
summary: - The v3 authentication API should account for different scopes
+ The v3 token API should account for different scopes
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers