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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
