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