Open Stack

+1 to all points below.

On 02/13/2013 09:33 AM, Adam Young wrote:
> 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
>