A Keystone user can't perform revoke_token operation due to absence of target in context
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Fix Released
|
Medium
|
Arvind Tiwari |
Bug Description
The default policy file which comes with keystone has "["user_
For all the below listed APIs there is not target set, the way it happens for API like "GET /users/{user_id}", in this case "["user_
identity:
identity:
identity:
This issue can lead to a security vulnerability because token will stay active till its life.
Fix: In my opinion we should use "X-Subject-Token" which is coming in the header to derive the target for auth check.
Changed in keystone: | |
assignee: | nobody → Arvind Tiwari (arvind-tiwari) |
Changed in keystone: | |
status: | Triaged → Fix Committed |
Changed in keystone: | |
milestone: | none → icehouse-1 |
status: | Fix Committed → Fix Released |
Changed in keystone: | |
milestone: | icehouse-1 → 2014.1 |
Should these calls require any authentication at all (with a default policy configuration)? If the caller is in possession of a token, why should they not be able to validate or revoke it? Revoking your own token is analogous to "logging out."
I definitely *don't* think that these calls should receive special treatment in terms of how X-Auth-Token vs X-Subject-Token is handled. In other words, the X-Subject-Token should not be treated as an X-Auth-Token, and if policy.json requires authorization, that should apply to the X-Auth-Token.
I'm not sure if this is a security vulnerability though, because the token can still be revoked on the v2 API.