The v3 token API should account for different scopes

[Lance Bragstad]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/665231

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/665231
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=092570fc5ef43497c29cf174bfff43323a49fb58
Submitter: Zuul
Branch: master

commit 092570fc5ef43497c29cf174bfff43323a49fb58
Author: Lance Bragstad <email address hidden>
Date: Thu Jun 13 20:12:56 2019 +0000

    Implement system scope and default roles for token API

    This commit adds protection testing for the token API along with
    changes to default policies to properly consume system-scope and
    default roles.

    Originally, this work was going to include the ability for project and
    domain administrator to validate, check, or revoke tokens within the
    context of their authorization (e.g., a domain administrator could
    revoke tokens on projects within their domain). This seems like extra
    work for not much benefit since we're using bearer tokens. The holder
    of the token can do anything with that token, which means they can
    validate it or revoke it without using their own token. Adding
    project and domain administrator support seems unnecessary given the
    existing functionality. If someone comes forward asking for this
    functionality, we can re-evaluate the effort. For now, this patch is
    limited to system user support, allowing them to validate, check, and
    revoke any token in the system. Service users can still validate
    tokens on behalf of users. Users can do anything they wish with their
    own tokens.

    This commit also bumps the minimum version of oslo.log so that we can
    use the official TRAIN deprecated release marker.

    Change-Id: Ia8b35258b43213bd117df4275c907aac223342b3
    Closes-Bug: 1818844
    Closes-Bug: 1750676

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 16.0.0.0rc1 release candidate.