<html><body>
<p><font size="2" face="sans-serif">Hey David,</font><br>
<br>
<font size="2" face="sans-serif">1. and 5. The delegate is not always known to keystone. The delegate (I like to say consumer) would use an oauth client (web-based one here </font><a href="http://term.ie/oauth/example/client.php"><font size="2" color="#0000FF" face="sans-serif"><u>http://term.ie/oauth/example/client.php</u></font></a><font size="2" face="sans-serif">); in an oauth flow, the delegate requires a key/secret pair, they don't have to be already known to keystone. (Apologies if my keystoneclient example led you to believe that)</font><br>
<br>
<font size="2" face="sans-serif">3. The authorizing step happens later on, 1e; any user with sufficient credentials (the role matching the requested role), can authorize the request token. If you don't expect the delegate to have knowledge of roles, they shouldn't have knowledge of users either; so specifying one wouldn't make things easier.</font><br>
<br>
<font size="2" face="sans-serif">2. Continuing with my previous answer, to authorize a request token, the requested role would have to be a subset of the delegator roles. Otherwise any user could authorize the token.</font><br>
<br>
<font size="2" face="sans-serif">4. When using an oauth client, the delegate would input both the key and secret; the client would then sign the request and send only the key and *other oauth specific variables* over to the server side.</font><br>
<font size="2" face="sans-serif"><br>
<br>
Thanks,<br>
<br>
_____________________________________________<br>
Steve Martinelli | A4-317 @ IBM Toronto Software Lab<br>
Software Developer - OpenStack<br>
Phone: (905) 413-2851<br>
E-Mail: stevemar@ca.ibm.com</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF11CDFC18A0F8f9e8a93df938@ca.ibm.com" border="0" alt="Inactive hide details for David Chadwick ---06/14/2013 10:45:34 AM---Hi Steve Can I ask a few questions about this please"><font size="2" color="#424282" face="sans-serif">David Chadwick ---06/14/2013 10:45:34 AM---Hi Steve Can I ask a few questions about this please</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">David Chadwick <d.w.chadwick@kent.ac.uk></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">OpenStack Development Mailing List <openstack-dev@lists.openstack.org>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Cc: </font><font size="1" face="sans-serif">Steve Martinelli/Toronto/IBM@IBMCA</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">06/14/2013 10:45 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">Hi Steve<br>
<br>
Can I ask a few questions about this please<br>
<br>
1. Step 0b. Why do we need a new consumers table containing essentially <br>
un/pw pairs for the delegate (called key/secret in the spec) when the <br>
delegate is already known to keystone and can authenticate using its <br>
existing credentials?<br>
<br>
2. Step 1b. How does the delegate know which role to request? This is <br>
unintuitive. A delegator (rather than delegate) knows the role he wants <br>
to delegate. One would normally expect the delegator to request Keystone <br>
to delegate this role to the named delegate, rather than the delegate <br>
asking for a role to be delegated to it, since it requires an out of <br>
band communications between the delegator and delegate to take place <br>
before the delegation, in which the delegator tells the delegate its <br>
un/pw and the role it should ask for. This seems to be a rather <br>
contrived exchange of messages.<br>
<br>
3. Step 1b. Why does the delegate not specify who should do the <br>
delegation?. This is another unintuitive feature. A delegate would not <br>
normally simply ask a service to give it a role, since the service is <br>
not empowered to do this. It has to be the existing role holder (the <br>
delegator) who has to authorise this, but in step 1b the delegator is <br>
not mentioned.<br>
<br>
4. In step 1b the delegate is only authenticating itself via its <br>
username/key, and this was specified by the delegator when he created <br>
the new consumer in step 0b. So the delegator could have used a simple <br>
name/key like Fred, which means that it would then be very easy for <br>
anyone to masquerade as the delegate. Wouldnt it be better to require <br>
both the un/pw (key/secret) in this exchange rather than simply the key? <br>
The same security weakness is in step 1f as well.<br>
<br>
5. What is the purpose of having the delegate's secret?<br>
<br>
regards<br>
<br>
David<br>
<br>
<br>
On 14/06/2013 14:31, Steve Martinelli wrote:<br>
> Greetings!<br>
><br>
> I've implemented the following blueprint for keystone: Delegated Auth a<br>
> la Oauth [1<br>
> <</font></tt><tt><font size="2"><a href="https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth">https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth</a></font></tt><tt><font size="2">>].<br>
> The original spec [2 <</font></tt><tt><font size="2"><a href="https://gist.github.com/termie/5225817">https://gist.github.com/termie/5225817</a></font></tt><tt><font size="2">>] has a<br>
> use case to help understand why we are providing this ability in Keystone.<br>
> If you're familiar with keystone, or just familiar with Oauth, I'd<br>
> really appreciate your input. There are two change sets; a keystone<br>
> patch [3 <</font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/29130/">https://review.openstack.org/#/c/29130/</a></font></tt><tt><font size="2">>] and keystoneclient<br>
> patch [4 <</font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/30043/">https://review.openstack.org/#/c/30043/</a></font></tt><tt><font size="2">>].<br>
><br>
> Thanks!<br>
><br>
> References:<br>
> 1. </font></tt><tt><font size="2"><a href="https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth">https://blueprints.launchpad.net/keystone/+spec/delegated-auth-via-oauth</a></font></tt><tt><font size="2"><br>
> 2. </font></tt><tt><font size="2"><a href="https://gist.github.com/termie/5225817">https://gist.github.com/termie/5225817</a></font></tt><tt><font size="2"><br>
> 3. </font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/29130/">https://review.openstack.org/#/c/29130/</a></font></tt><tt><font size="2"><br>
> 4. </font></tt><tt><font size="2"><a href="https://review.openstack.org/#/c/30043/">https://review.openstack.org/#/c/30043/</a></font></tt><tt><font size="2"><br>
><br>
><br>
> Thanks,<br>
><br>
> _____________________________________________<br>
> Steve Martinelli | A4-317 @ IBM Toronto Software Lab<br>
> Software Developer - OpenStack<br>
> Phone: (905) 413-2851<br>
> E-Mail: stevemar@ca.ibm.com<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
><br>
<br>
</font></tt><br>
</body></html>