Open Stack

Hi Adam, 

I would like to verify my understanding of trusts and their token renewal. 
Please read the flow below and comment whether we can achieve this.  I 
know that there are still some missing parts at the Swift side, but I 
would like to clarify the trusts flow before addressing them. 

Thank you very much,
Alex. 

Motivation: 
User A wants to grant user B an access to container (C). User A is the 
owner of C. 

Delegation flow: 
1. By using the API of trusts, user A (having roles X and Y) registers a 
"trust" to user B, granting him role X sufficient to access container C. 
2. User B, sends a request for a token defined by this trust. User B 
authenticates with his own credential (token or username&password of user 
B). 
3. Based on the defined trust user B is granted a token authorizing him to 
have role X. User B is listed as a "trustee" in the generated token (T). 
4. User B presents the token T to Swift and gains access to container C. 
5. When the token is expired, user B can renew it by repeating the steps 
2-3 above. 



From:   Adam Young <ayoung at redhat.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>, 
Date:   13/02/2013 04:34 PM
Subject:        [openstack-dev] [Keystone] Proposed change to token 
re--issue



Right now, Keystone will allow you to get a token based on a previous 
token.   It does not matter if the original token is for a different 
scope, more restricted, than the second token.


While writing the trusts implementation, I realize that carrying this 
rule forward would open up a security hole.  A user with a token based 
on a trust would be able to get a new token for any of the privileges of 
the trustor.  The whole point of trusts was to scale down the scope of 
access from a token, not to increase it.

I would like to propose the following rule. It will have to apply to 
both the V2 and V3 versions of the APIs.

Only an unscoped token can be used to retrieve another token.


In order to get an unscoped token, you have to pass in userid and 
password, or one of the REMOTE_USER mechanisms.
It is technically OK to use an unscoped token to get another token, so 
long as the time out is honored, but I am not sure if that provides any 
real benefit.

I could make a one-off exception for trust tokens.  However, if we don't 
address this issue now, I suspect it will come back to haunt us later.

Here is a longer rationalization.

Tokens are a symetric shared secret.  If you have the token, you have 
the permissions of the user.  Thus, a token should not be spread 
around.  Ideally, tokens should contain just the minimal amount of 
permissions to accomplish the task at hand.  THat way, if they get 
intercepted, they can only be used to do minimal amounts of damage.  If 
a user has access to multiple projects (tenants), the token shoud not 
provide access to the tenants other than the one for which it is 
allocated.  Right now, due to token reissue,  a token for Project A can 
be used to get a token for Project B.

In the future, we are talking about scoping tokens to domains, 
endpoints, and other containers.  Lets choose now to limit the amount of 
exposure on a single token.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130218/93829b55/attachment.html>