Open Stack

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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>