yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

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