No reissue for scoped tokens

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.