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 <lbrags...@gmail.com> 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 -- 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