Open Stack

On 10/11/2012 01:04 AM, heckj wrote:
> Hey Adam,
>
> Wanted to hit you directly - I wasn't clear on what the semantics were that you're aiming for with a "pre-authenticated" token.
Hope you don't mind me responding to the mailing list, since I suspect 
most people have these questions.


>
> We have somewhat similar critters in handing over some related auth (EC2 credentials, and a variation of that theme for Swift TempAuth).
>
> What are the key aspects of how one of these "special tokens" is expected to work? From what I've seen so far, it seems like a token that disobeys or has alternate semantics, but it's not entirely clear to me what they are or what we're trying to get with it? Is this sort of a one-shot token concept?

Pre auth is not a token, so much as it is a contract:  user A is allowed 
to get a token for user B.  User A needs to be authenticated already in 
order to get a token for user B.  After that, the token looks exactly 
like a token for B that user B got themself.

I don't see it as one shot.  I see it as a way to let services do work 
for another user at some time in the future.

I probably should also explicitly state that preauthentication should be 
limited to a specific project/tenant.  This, coupled with a rule that 
says a scoped token cannot be used to get an unscoped token, or a token 
scoped to another project, also correctly limits the degree to which one 
user account can impersonate another user account.


The difference with the EC2 and switft credentials is that they are all 
associated with a single user account.  This is explicitly a way to 
cross over from one account to another.

>
> -joe
>
> On Oct 10, 2012, at 1:24 PM, Adam Young <ayoung at redhat.com> wrote:
>> On 10/09/2012 10:16 PM, Adam Young wrote:
>>> One issue that I've been asked about repeatedly is getting a token for an action in the future.  Two use cases for this have come up:
>>>
>>> 1.  HEAT and failover.  It needs to move a virtual machine from one host to another.
>>> 2.  Content production.    Something generates a large file and needs to store it in swift.
>>>
>>> In both cases, the users authorizes it at setup time to perform this action any time in the future, long after the token is expired.
>>>
>>> To support this, add two new APIs.  One is POST preauthenticate, and the other is GET preauthenticate/{user_id}
>>>
>>> When POSTing to preauthenticate,  the user supplies a user that will be allowed to fetch a token at some point in the future.
>>>
>>> When GETting tokens/preauthenticated/{user_id}  only the specified user will be able to fetch a token for the user that performed the preauthenticate action.
>>>
>>> We could potentially add an additional PATCH to modify a pre-auth arraingement.  We would certainly want a DELETE.
>>>
>>> The preauthentication id should  be just a UUID.  It should be useless to anyone but the user that creates it.  No other user should be able to view it.  The user should be able to enumerate her preauthentications, in order to view, modify, and delete them. /users/preauthentications
>> https://blueprints.launchpad.net/keystone/+spec/pre-auth
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev