Open Stack

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