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
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

[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

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

Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
status: Triaged → In Progress

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

Changed in keystone:
status: In Progress → Fix Released

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers