Regarding my blueprint https://blueprints.launchpad.net/python-keystoneclient/+spec/keystoneclient-auth-token and Guang's bug https://bugs.launchpad.net/python-keystoneclient/+bug/1207922 (auth_token middleware always use v2.0 to request admin token), i'm trying to make a v3 client capable of validating a UUID token.
For V2 without domains the concept of an admin user/role is simple and so to validate UUID tokens from auth_token middleware you simply need a username/password or token. For V3 do we have any concept of what policies will need to be in place to say that a user has the privilege to validate another user's token. The problem comes in that to use the client we should scope a user to a domain or a project. If you don't do this you don't receive the catalog of links, and the client is not populated with the management_url you should be using for identity. A solution to this would be to hack around the issue and just assume that if a v3 client is instantiated with an unscoped client then you assume that the management url is the same as the client discovered url. This is generally wrong, but also i'm not sure that the call to POST /v3/auth/token makes sense when authenticated with an unscoped token. Using username in v3 is also not appropriate without specifying the domain name that the username is unique to so at the very least this will need to get added to auth_token. However what happens with a scoped token? If auth_token has a token scoped differently to the token it is validating then the same 'admin' role should not apply (at least theoretically, i've only been an observer on the roles/domains debates). The best way i can see out of it is a special type of role or domain whose users have certain permissions across all the keystone domains. Is there something like this already? Is the 'admin' concept global across domains? Can someone with a better understanding of roles, policy, and domains in V3 explain how this should work? Thanks, Jamie _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev