Activity log for bug #1748027

Date Who What changed Old value New value Message
2018-02-07 22:06:53 Lance Bragstad bug added bug
2018-02-07 22:07:08 Lance Bragstad tags policy
2018-02-07 22:10:07 Lance Bragstad 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]. 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 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
2018-02-11 21:02:23 Lance Bragstad keystone: importance Undecided High
2018-02-11 21:02:31 Lance Bragstad keystone: status New Triaged
2018-03-27 02:15:06 Dmitrii Shcherbakov bug added subscriber Dmitrii Shcherbakov
2018-04-04 09:55:09 sonu keystone: assignee sonu (sonu-bhumca11)
2018-09-19 11:15:06 Colleen Murphy tags policy policy system-scope
2018-10-16 21:41:58 OpenStack Infra keystone: status Triaged In Progress
2018-10-16 21:41:58 OpenStack Infra keystone: assignee sonu (sonu-bhumca11) Lance Bragstad (lbragstad)
2019-03-23 23:04:16 OpenStack Infra keystone: status In Progress Fix Released
2019-03-24 15:02:17 Colleen Murphy keystone: milestone stein-rc2
2019-03-26 16:27:30 OpenStack Infra tags policy system-scope in-stable-stein policy system-scope