yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #74390
[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