Open Stack

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.