Hi Jamie, So potentially part of this solution may be one of the blueprints and implementation I am currently working on to allow policy rules to specify fields in the target entity that an API is accessing, see:
https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target https://review.openstack.org/#/c/38308/3 I have not yet quite completed this and am just about modify the auth controller to support this - potentially it could mean you could have a policy rule that meant, for instance, your user_id would have to match the one in the token that already existed (for the example you raise)? As to the general need for a description of how policy, domains & roles all work togther - I'm going to be writing this up for inclusion in the openstack docs for Havana - I'll let you see the draft as soon as I have it. Henry On 7 Aug 2013, at 09:07, Jamie Lennox wrote: > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
