yahoo-eng-team team mailing list archive

[OpenStack Infra <1748027@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/623322
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=f9e07a940dc6d197709f5a66c8e4ff203d388da1
Submitter: Zuul
Branch:    master

commit f9e07a940dc6d197709f5a66c8e4ff203d388da1
Author: Lance Bragstad <lbragstad@xxxxxxxxx>
Date:   Thu Dec 6 21:01:14 2018 +0000

    Add explicit testing for project users and the user API
    
    This commit wraps up the user API policy refactor by adding explicit
    testing for how project users are expected to behave with the user
    API. A subsequent patch set will remove the now obsolete user policies
    in policy.v3cloudsample.json.
    
    Change-Id: Ic7b0839ac70439aa0311a98c6b7b5688a7e2dcf7
    Closes-Bug: 1748027
    Related-Bug: 968696


** 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/1748027

Title:
  The v3 users 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 [0]. 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
  [1].

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

  GET /v3/users/{user_id}

  - Someone with a system role assignment that passes the check string should be able to call this API for any user in the system
  - Someone with a domain role assignment that passes the check string should be able to call this API for any user within the domain
  - Someone with a valid token should be able to call this API for their user

  GET /v3/users

  - Someone with a system role assignment that passes the check string should be able to call this API and get a list of all users in the system
  - Someone with a domain role assignment that passes the check string should be able to call this API and get a list of all users within that domain

  POST /v3/users

  - Someone with a system role assignment that passes the check string should be able to create users anywhere in the system
  - Someone with a domain role assignment that passes the check string should only be able to create users within their domain
  - Someone with a project role assignment that passes the check string shouldn't be able to create users since users are domain-scoped entities.

  PATCH /v3/users/{user_id}

  - Someone with a system role assignment that passes the check string should be able to update any user in the system
  - Someone with a domain role assignment that passes the check string should only be able to update users within their domain, this should also include rejecting requests to update domain IDs for users that doesn't match the domain they are a part of
  - Someone with a project role assignment that passes the check string shouldn't be able to update users since users are domain-scoped.

  [0] https://review.openstack.org/#/c/526203/
  [1] https://review.openstack.org/#/c/526203/5/keystone/common/policies/user.py@21

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