gistfile1.txt

A Q&A done in email.  Questions are mine, answers are from termie

ayoung:    The immediate thing that jumps out to me as an improvement over trusts is that it standardizes the way that the remote service requests the set of roles.  That was something that I punted on.  I mean, beyond actually using a standard protocol.    If I understand it correctly, Trusts is really just an implementation of the second half of oauth, from steps 1e onward.  The terms used are different, and Trusts doesn't work for non-Keystone services.

    From a security standpoint, nothing jumps out at me as being a weakness in the description.  A couple details we should make explicit:

    The most pressing need we have is for delegation internal to Open Stack, when a service that is itself authenticated to Keystone needs to fetch something for a user out of Glance, and the user is not available at that time.  I think this is what you mean by "If you are just giving a service you are already running access" and by skip to the end it would be when you set up the "agreement" with that service.

    In the case of purely internal delegation, I assume we would not need &oauth_token_secret=some_other_uuid and instead the remote service would authenticate with one of the mechanisms that Keystone already recognize: either uid/passwrod, an existing token, or some other extension.


termie: "Purely internal" is probably not the case, what we're talking about for most of these is more like I am going to use some off-the-shelf HA provider, we could just give it both sets of credentials and be done with it. The interesting cases down the line will be for the *aaS providers where they may be providing services for multiple users in your system (or if you simply run your company internally along similar models)
 

ayoung:      I'm assuming the Consumer and Requests tables would replace the trusts table.  However, would you keep the roles and other attributes normalized as they are now, or would you do a "extra" or "metadata" type serialization of the attributes to be delegated?


termie:  I am a fan of not indexing things I don't need to, so I usually prefer database schemas that enforce that behavior and knowledge (hah) through use of blobs, if that is what you are talking about. Right now all we have is role scoping but additional data could probably be useful in the future, especially for extensions.
 

ayoung:  Consumer allows external entities beyond those managed by Keystone, but for those that are in Keystone, would we have a (not enforced, but logical) Foreign Key to the user table?  I assume that a given Consumer would be either/or: a User  from the identity backend, OR an external entity with its own shared secret.


termie:  If you are trying to delegated permissions to a user it would make more sense just to give that user roles in your project.



ayoung:  In step 1f, you state "Abby hands the oauth_verifier code to ScaleMe out-of-band"  what does this mean?  I assume it a direct HTTPS response to the ScaleMe server that Abby talked to in the first place."  Is there anything Out of band" about this beyond that


termie: It is out of band in that it isn't defined for a cli interaction how ScaleMe wants Abby to respond, just that ScaleMe will need to get that code. 

 

ayoung:   Also in 1f, you have a couple links that look suspiciously like we are putting secrets into the URL parameters.  Is this just an artifact of the formatting?  We should avoid putting secrets in the URLs, so that they don't show up in server logs.  Request params should be OK, though, and I think you just left off the ? for those, right?


termie: There are no secrets in urls, consumer_key != consumer_secret, etc, I'm not sure which things you think are in the URL, but oauth uses signing so secrets aren't passed around. I also punted on defining whether those should be GET or POSTs (oauth traditionally has used GETs but that is largely so that links can be provided to users, I don't think it will make a difference either way to us but it might be nice to reserve the GET calls for a web interface).
 


ayoung: How much leeway do we give ScaleMe in getting a token for doing things as Abby?  I would think that we would want to lock the set of roles etc down to exactly what Abby made in her /oauth/authorize request.  What kind of information would have to be sent in &abunchofoauthspecificvariables?


termie:  You really mix a lot of different questions into the same paragraph, sir.

The roles were locked down in the 1b-1c step. My suggestion is to pass the requested roles in to the authorization request to make sure that Abby knows which roles have been requested (there are fewer opportunities to inform the user when not in a web context).
 
The oauth specific variables are things like a timestamp and nonce that are part of the signature (traditionally the timestamp is rather loosely enforced to allow for clock skew and nonces are tombstoned long enough to be kept around until that window expires)