Limit the rescoping of tokens to prevent unauthorized reuse or escalation of privileges.
An unscoped token can be used to obtain a token scoped to any project or domain. However, once a user is in possession of a scoped token, that user, or any user, which obtains the token is able to exchange it for another project scoped token. This should not be allowed, since it means that any token is effectively unconstrained. In order to exchange a scoped token to an unscoped token the user should have to re-authenticate to prove entitlement to the unscoped token. A user should never be able to exchange one scoped token for a differently scoped token.
Constrain the token creation process so that: * A user must authenticate in order to obtain an unscoped token. * Only tokens that are unscoped can be exchanged for a token that is scoped to a domain or project. * A token that is scoped to a domain or project cannot be exchanged for another token.
This should be hidden from the end user in just about every case. The one exception is people making direct CURL calls to Keystone. The Keystone client will make this seemless elsewhere.
Many requests for a single, scoped, token will now require multiple tokens. First one will be unscoped, second will be scoped. Horizon will be the primary consumer that sees this. However, in LDAP deployments, Horizon already works this way.
Discuss things that will affect how you deploy and configure OpenStack that have not already been mentioned, such as:
A Config flag to enable and disable this feature
Needs to be explicitly enabled
All services that need multiple tokens will have to hold on to one unscoped token to get the other tokens. This should be managed by the keystone client.