yahoo-eng-team team mailing list archive

[Dolph Mathews <1153080@xxxxxxxxxxxxxxxxxx>]

No, it's not the same data and you probably shouldn't have authz there
for this use case. By design, v3 is intending to correct a very strange
behavior in the v2 API. That is, the following call is used by users to
list tenants to which they have access:

  http://identity:5000/v2.0/tenants

Administrators would use the following endpoint to list all tenants in
the system:

  http://identity:5000/v2.0/tenants

Note that the only different between the above two calls is the port
used. This is the only difference I'm aware of between the two v2
endpoints.

In v3, users list the "projects" to which they have access by calling:

  http://identity:35357/v3/users/{my_user_id}/projects

And the domains to which they have access by calling:

  http://identity:35357/v3/users/{my_user_id}/domains

This frees up the following two root collections to actually list all
resources in the system, as expected:

  http://identity:35357/v3/domains
  http://identity:35357/v3/projects

Also note that there are no behavioral differences on /v3/ between :5000
and :35357 as a result of this design change.

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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1153080

Title:
  GET v2.0/tenants authority vs GET v3/projects

Status in OpenStack Identity (Keystone):
  Invalid

Bug description:
  
  Using the default setup with devstack, a non-administrator can get tenants using v2.0 API, but using the V3 API to get projects, it fails saying I don't have authority. It's the same data, so non-administrators should either have access to it or not have access to it via any api.

  To recreate:

  0) start with devstack.

  1) Get a demo user token:

  $ keystone tenant-get demo
  ...
  |      id     | 0f434bbbfabc461c94aa0f277d3c456a |

  $ DEMO_TENANT_ID= 0f434bbbfabc461c94aa0f277d3c456a

  $ curl -i \
   -H "Content-Type: application/json" \
   -d '{"auth":{"passwordCredentials":{"username":"demo","password":"ofs5dac"},"tenant":"$DEMO_TENANT_ID"}}' \
   http://localhost:5000/v2.0/tokens ; echo

  $ DEMO_TOKEN=...

  2) Get tenants using the v2 API:

  $ curl  -H "X-Auth-Token: $DEMO_TOKEN"  http://localhost:5000/v2.0/tenants ; echo
  {"tenants_links": [], "tenants": [{"description": null, "enabled": true, "id": "0f434bbbfabc461c94aa0f277d3c456a", "name": "demo"}, {"description": null, "enabled": true, "id": "4880ab65f26046e690228d5ba0660b02", "name": "invisible_to_admin"}]}

  3) Now try to get tenants/projects using the v3 API:

  $ curl  -H "X-Auth-Token: $DEMO_TOKEN"  http://localhost:5000/v3/projects ; echo
  {"error": {"message": "You are not authorized to perform the requested action: identity:list_projects", "code": 403, "title": "Not Authorized"}}

  
  Keystone should be consistent about either denying or allowing tenant/project data to non-administrators.

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