yahoo-eng-team team mailing list archive

[OpenStack Infra <1750676@xxxxxxxxxxxxxxxxxx>]

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 <lbragstad@xxxxxxxxx>
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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1750676

Title:
  The v3 token API should account for different scopes

Status in OpenStack Identity (keystone):
  Fix Released

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1750676/+subscriptions