The v3 token API should account for different scopes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Lance Bragstad |
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
tags: | added: system-scope |
summary: |
- The v3 authentication API should account for different scopes + The v3 token API should account for different scopes |
Fix proposed to branch: master /review. opendev. org/665231
Review: https:/