Public bug reported: 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 ** Affects: keystone Importance: High Status: Triaged ** Tags: policy -- 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 authentication API should account for different scopes Status in OpenStack Identity (keystone): Triaged 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 : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
