← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1788415] [NEW] The credential API should account for different scopes

 

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 credential API
should behave with tokens from multiple scopes:

GET /v3/credentials/{credential_id}

- Someone with a system role assignment that passes the check string should be able to view credentials for any user in the deployment (system-scoped)
- Someone with a valid token should only be able to view credentials they've created

GET /v3/credentials/

- Someone with a system role assignment that passes the check string should be able to list all credentials in the deployment (system-scoped)
- Someone with a valid token should only be able to list credentials associated to their user

POST /v3/credentials

- Someone with a system role assignment that passes the check string should be able to create credentials for other users (system-scoped)
- Someone with a valid token should only be able to create credentials for themselves

DELETE /v3/credentials/{credential_id}

- Someone with a system role assignment that passes the check string should be able to delete any credential in the deployment (system-scoped)
- Someone with a valid token should only be able to delete credentials associated to their user account

[0]
https://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/credential.py#n21

** Affects: keystone
     Importance: High
         Status: Triaged


** Tags: policy

** Changed in: keystone
       Status: New => Triaged

** Changed in: keystone
   Importance: Undecided => High

** Tags added: 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/1788415

Title:
  The credential 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 credential API
  should behave with tokens from multiple scopes:

  GET /v3/credentials/{credential_id}

  - Someone with a system role assignment that passes the check string should be able to view credentials for any user in the deployment (system-scoped)
  - Someone with a valid token should only be able to view credentials they've created

  GET /v3/credentials/

  - Someone with a system role assignment that passes the check string should be able to list all credentials in the deployment (system-scoped)
  - Someone with a valid token should only be able to list credentials associated to their user

  POST /v3/credentials

  - Someone with a system role assignment that passes the check string should be able to create credentials for other users (system-scoped)
  - Someone with a valid token should only be able to create credentials for themselves

  DELETE /v3/credentials/{credential_id}

  - Someone with a system role assignment that passes the check string should be able to delete any credential in the deployment (system-scoped)
  - Someone with a valid token should only be able to delete credentials associated to their user account

  [0]
  https://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/credential.py#n21

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1788415/+subscriptions


Follow ups