The credential API should account for different scopes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
High
|
Lance Bragstad |
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
- 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
- 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:/
Changed in keystone: | |
status: | New → Triaged |
importance: | Undecided → High |
tags: | added: policy |
Changed in keystone: | |
assignee: | nobody → Lance Bragstad (lbragstad) |
status: | Triaged → In Progress |
tags: | added: system-scope |
Changed in keystone: | |
milestone: | none → stein-2 |
Related fix proposed to branch: master /review. openstack. org/597187
Review: https:/