Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth
Hi David, This email is long overdue. 1. I don't recall ever stating that we were going to use OAuth 1.0a over 2.0, or vice versa. I've checked https://etherpad.openstack.org/havana-saml-oauth-scim and https://etherpad.openstack.org/havana-external-auth and couldn't find anything that said definitively that we were going to use 2.0. OAuth provider implementations (in python) of either version of the protocol are few and far between. 2. I think I'm going to regret asking this question... (as I don't want to get into a long discussion about OAuth 1.0a vs 2.0), but what are the security weaknesses you mention? 3. I think you are disagreeing with the consumer requesting roles? And are suggesting the consumer should be requesting an authorizing user instead? I'm not completely against it, but I'd be interested in what others have to say. 4. Regarding the evil consumer; we do not just use the consumer key, the magic oauth variables I mentioned also contain oauth_signature, which (if you are using a standard oauth client) is the consumers secret (and other values) and also hashed. On the server side, we grab the consumer entity from our database and recreate the oauth_signature value, then verify the request. If the evil consumer did not provide a provide a secret, (or a wrong secret) it would fail on the verify step on the server side (signatures wouldn't match). If the evil consumer used his own library, he would still need to sign the request correctly (done only with the correct consumer key/secret). Thanks, _ Steve Martinelli | A4-317 @ IBM Toronto Software Lab Software Developer - OpenStack Phone: (905) 413-2851 E-Mail: steve...@ca.ibm.com From: David Chadwick d.w.chadw...@kent.ac.uk To: Steve Martinelli/Toronto/IBM@IBMCA, Cc: openstack-dev@lists.openstack.org Date: 06/19/2013 04:38 PM Subject:Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth Hi Steve On 19/06/2013 20:56, Steve Martinelli wrote: Hey David, 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 _http://term.ie/oauth/example/client.php_); 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) I know that in Oauth the consumer is not always known to the resource provider (Keystone) but Oauth has security weaknesses in it which OAuth2 has fixed. So I would hope we are not going to use Oauth as the general delegation model. I thought that the last design summit agreed that Oauthv2 should be the right way to go for general delegation, and that Oauth was only going to be used to replace Adam's existing delegation scheme in which all the entities are known to Keystone. So consider this, where the consumer is not known to Keystone. Keystone trusts the user, and the user trusts the consumer to access his resources on Keystone/OpenStack. Keystone has no idea who the consumer is. Now we all know that users are easily tricked by spear phishing, spam and the rest into trusting evil sites, so an evil consumer tricks the user and now OpenStack is open to abuse as the naive user has given his privileges away to an evil consumer. Surely you cannot be saying that we should build support for this into OpenStack and Keystone are you? So I would propose that the OAuth delegation system you are building is restricted to only work with entities that are already known to Keystone and have been registered there by trusted administrators, who should be much more difficult to trick than naive users. In other words, Keystone should not provide full unrestricted support for OAuth delegation, that should be reserved for OAuthv2 (or whatever the group decides). 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. The delegate/consumer has knowledge of the user (delegator) since it is in direct communication with him/her. (They have to be in order for the secret to be passed between themselves). The delegate does not a priori have any knowledge of what should be delegated to it (the role). Only the delegator knows this. So I do not follow your logic. 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. We are agreed on this point, for sure. 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
Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth
On 19/07/2013 07:10, Steve Martinelli wrote: Hi David, This email is long overdue. 1. I don't recall ever stating that we were going to use OAuth 1.0a over 2.0, or vice versa. I've checked _https://etherpad.openstack.org/havana-saml-oauth-scim_and _https://etherpad.openstack.org/havana-external-auth_and couldn't find anything that said definitively that we were going to use 2.0. OAuth provider implementations (in python) of either version of the protocol are few and far between. As I recall, there was a presentation from David Waite, Ping Identity, about OAuth2, and after this it was agreed that OAuth2 would be used as the generic delegation protocol in OpenStack, and that OAuth1 would only be used as an alternative to the existing trusts delegation mechanism. If this is not explicitly recorded in the meeting notes, then we will need to ask others who were present at the design summit what their recollections are. 2. I think I'm going to regret asking this question... (as I don't want to get into a long discussion about OAuth 1.0a vs 2.0), but what are the security weaknesses you mention? These are documented in RFC 5849 (http://tools.ietf.org/rfc/rfc5849.txt) which is presumably the specification of OAuth1 that you are implementing. There is also a session fixation attack documented here http://oauth.net/advisories/2009-1/ 3. I think you are disagreeing with the consumer requesting roles? And are suggesting the consumer should be requesting an authorizing user instead? I'm not completely against it, but I'd be interested in what others have to say. If the use case is to replace trusts, and to allow delegation from a user to one or more openstack services then yes, it should be the user who is wanting to launch the openstack service, and not any user who happens to have the same role as this user. Otherwise a consumer could get one user to authorise the job of another user, if they have the same roles. If the use case is general delegation, then relating it to Adam's post: http://adam.younglogic.com/2013/07/a-vision-for-keystone/ in order to future proof, the consumer should request authorising attributes, rather than roles, since as Adam points out, the policy based authz system is not restricted to using roles. 4. Regarding the evil consumer; we do not just use the consumer key, the magic oauth variables I mentioned also contain oauth_signature, which (if you are using a standard oauth client) is the consumers secret (and other values) and also hashed. This solves one of my problems, because now you are effectively saying that the consumer has to be pre-registered with Keystone and have a un/pw allocated to it. I did not see this mentioned in the original blueprint, and thought (wrongly) that anything could be a consumer without any pre-registration requirement. So the pre-registration requirement removes most probability that the consumer can be evil, since one would hope that the Keystone administrator would check it out before registering it. regards david On the server side, we grab the consumer entity from our database and recreate the oauth_signature value, then verify the request. * If the evil consumer did not provide a provide a secret, (or a wrong secret) it would fail on the verify step on the server side (signatures wouldn't match). * If the evil consumer used his own library, he would still need to sign the request correctly (done only with the correct consumer key/secret). Thanks, _ Steve Martinelli | A4-317 @ IBM Toronto Software Lab Software Developer - OpenStack Phone: (905) 413-2851 E-Mail: steve...@ca.ibm.com Inactive hide details for David Chadwick ---06/19/2013 04:38:56 PM--- Hi Steve On 19/06/2013 20:56, Steve Martinelli wrote:David Chadwick ---06/19/2013 04:38:56 PM--- Hi Steve On 19/06/2013 20:56, Steve Martinelli wrote: From: David Chadwick d.w.chadw...@kent.ac.uk To: Steve Martinelli/Toronto/IBM@IBMCA, Cc: openstack-dev@lists.openstack.org Date: 06/19/2013 04:38 PM Subject: Re: [openstack-dev] [Keystone] Reviewers wanted: Delegated Auth a la Oauth Hi Steve On 19/06/2013 20:56, Steve Martinelli wrote: Hey David, 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 _http://term.ie/oauth/example/client.php_); 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) I know that in Oauth the consumer is not always known to the resource provider (Keystone) but Oauth has security weaknesses in it which OAuth2 has fixed. So I would hope we are not going to use Oauth as the general delegation model. I thought that the last design summit agreed that Oauthv2 should
