Token Scoping

[Abu Shohel Ahmed]

In Havana Stable release for both V2.0 an V3,

A scoped token can be used to get another scoped or un-scopped token. This can be exploited by anyone who has gained access to a scoped token.

For example,

1. userA is related to two projects: Project1, Project2
2. userA creates tokenA scoped by Project1
3. userA shares the tokenA to a third party (malicious).
4. Third party can now make a token creation call to create a new tokenB scoped under projectB using tokenA.

Although, we know that bearer token has all or nothing property, scoping the token can limit the exposure.
A scoped token should not be allowed to create another scoped token.

[Dolph Mathews (dolph)]

Subscribed Adam Young, who has looked into this before, and I believe found a blocker to changing this behavior?

[Adam Young (ayoung)]

It would break Horizon.

On initial login, Horizon passes user id and password to the V2 API. If no tenant is specified, it gets s token scoped to the default tenant.

Even if it didn't, however, Horizon only holds on to the last token , and revokes all eralier, so you would break the ability to go from project to project.

[Malini Bhandaru (malini-k-bhandaru)]

Seems like horizon login page should take as input a "scope", domain (and even project possibly) to avoid such an issue.
Users are supposed to be unique per domain.

Then we could enforce any subsequent token creation to the domain and project of the current token. So no more or less harm than the token already leaked.

Further, we could limit horizon admin uses to only "read-only" on other domains/projects.

[Dolph Mathews (dolph)]

Implemented as part of:

  https://blueprints.launchpad.net/keystone/+spec/rescoping