Public bug reported:
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
** Affects: keystone
Importance: Undecided
Status: New
** Tags: policy
** Tags added: policy
** Description changed:
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
--
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):
New
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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
