Open Stack

Hi Steve

Can I ask a few questions about this please

1. Step 0b. Why do we need a new consumers table containing essentially 
un/pw pairs for the delegate (called key/secret in the spec) when the 
delegate is already known to keystone and can authenticate using its 
existing credentials?

2. Step 1b. How does the delegate know which role to request? This is 
unintuitive. A delegator (rather than delegate) knows the role he wants 
to delegate. One would normally expect the delegator to request Keystone 
to delegate this role to the named delegate, rather than the delegate 
asking for a role to be delegated to it, since it requires an out of 
band communications between the delegator and delegate to take place 
before the delegation, in which the delegator tells the delegate its 
un/pw and the role it should ask for. This seems to be a rather 
contrived exchange of messages.

3. Step 1b. Why does the delegate not specify who should do the 
delegation?. This is another unintuitive feature. A delegate would not 
normally simply ask a service to give it a role, since the service is 
not empowered to do this. It has to be the existing role holder (the 
delegator) who has to authorise this, but in step 1b the delegator is 
not mentioned.

4. In step 1b the delegate is only authenticating itself via its 
username/key, and this was specified by the delegator when he created 
the new consumer in step 0b. So the delegator could have used a simple 
name/key like Fred, which means that it would then be very easy for 
anyone to masquerade as the delegate. Wouldnt it be better to require 
both the un/pw (key/secret) in this exchange rather than simply the key? 
The same security weakness is in step 1f as well.

5. What is the purpose of having the delegate's secret?

regards

David


On 14/06/2013 14:31, Steve Martinelli wrote:
> Greetings!
>
> I've implemented the following blueprint for keystone: Delegated Auth a
> la Oauth [1
> <https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth>].
>   The original spec [2 <https://gist.github.com/termie/5225817>] has a
> use case to help understand why we are providing this ability in Keystone.
> If you're familiar with keystone, or just familiar with Oauth, I'd
> really appreciate your input. There are two change sets; a keystone
> patch [3 <https://review.openstack.org/#/c/29130/>] and keystoneclient
> patch [4 <https://review.openstack.org/#/c/30043/>].
>
> Thanks!
>
> References:
> 1. https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth
> 2. https://gist.github.com/termie/5225817
> 3. https://review.openstack.org/#/c/29130/
> 4. https://review.openstack.org/#/c/30043/
>
>
> Thanks,
>
> _____________________________________________
> Steve Martinelli | A4-317 @ IBM Toronto Software Lab
> Software Developer - OpenStack
> Phone: (905) 413-2851
> E-Mail: stevemar at ca.ibm.com
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>