V3 Identity API: Unscoped V2 tokens should be treated as domain-scoped tokens

[justinsb]

In the V2 API, there were I believe two types of token - an unscoped token and a token scoped to a project.

V3 adds a token scoped to a domain, and essentially makes it incredibly unlikely that an unscoped token will ever be returned (a user must not have a default project or must not have access to their default project).

When using the V2 API for authentication, I think that we should return a domain token when no project is specified, instead of an unscoped token (a V2 caller wouldn't be able to tell the difference). That seems to maximize compatibility. Otherwise if the server is V3 enabled and requires a domain token, there is no way for a V2 client to get a domain token. Conversely, when a V2 server requires a domain token, it presumably wants a token that is not bound to a particular project; that is exactly what an unscoped token is in V2.

[Dolph Mathews (dolph)]

This implies that a v2 API user must have v3 domain-level authorization.

> if the server is V3 enabled and requires a domain token, there is no way for a V2 client to get a domain token

correct

> when a V2 server requires a domain token

a v2-aware service would have no knowledge of domains, anyway

> when a V2 server requires a domain token, it presumably wants a token that is not bound to a particular project; that is exactly what an unscoped token is in V2

a domain-scoped token is a completely discrete concept from a project-scoped token, so this expectation would be invalid. further, unscoped tokens in v2 are analogous to unscoped token in v3, not to any other scoping concept in v3

[justinsb (justin-fathomdb)]

Oops: I meant "Conversely, when a V3 server requires a domain token". You're quite right that a V2 server doesn't have a concept of domains. I hope that makes more sense now.

In turn, you seem to have a typo of your own :-) I agree that "a domain-scoped token is a completely discrete concept from a project-scoped token", but I'm suggesting that a domain-scoped token has the same use-cases as a token scoped to _no_ project.

It seems to me we're breaking compatibility here when we don't have to, given what looks to me like an easy alternative (an unscoped token = a domain token).

What is the point of a distinction between an unscoped and a domain token in V3, given that it's almost impossible to get an unscoped token in V3? I know that they're described as different things, but _why_ are they different, given the huge cost.

[Dolph Mathews (dolph)]

> I hope that makes more sense now.

Yes it does!

> a domain-scoped token has the same use-cases as a token scoped to _no_ project

The only use case we support for unscoped tokens is that of authentication. Multifactor auth can be achieved by passing unscoped tokens back and forth before finally trading an unscoped token for one with authorization on a specific project or domain.

If you're going to argue that domain-scoped tokens support the same use case, you have to limit the conversation to domain-scoped tokens that have no roles, and therefore express no authorization over the referenced domain. At that point, the domain-scope is completely meaningless, and might as well be dropped.

> almost impossible to get an unscoped token in V3

Opinion.

> given the huge cost

Is there some context to this that I'm missing? What's the "huge cost?"

[justinsb (justin-fathomdb)]

> you have to limit the conversation to domain-scoped tokens that have no roles

I don't see why? Why can't I pass a domain-scoped token (a.k.a. unscoped token in my worldview) back and forth for multi-factor before trading it in for a project-scoped token if that's what I want?

> What's the "huge cost?"

If you add a new API (that must be used), every client binding must be changed. Every app that uses those bindings must be tested with the new client. Every deployed app must be updated. Every deployed cloud must be updated, otherwise they won't work with clients that require the new API. The ecosystem is damaged when people find it hard to use because "my Erlang binding can't authenticate against cloud X, but does work fine against cloud Y". Puppies die and babies cry.

The reality today, is that if I need a domain token for a particular Nova call (let's say), then I need to use a V3 Identity API client with a V3 Identity API server. It's not wise to assume that'll be the baseline for a few years yet, so nova won't require a domain token, it'll build in a V2 backdoor.

If, instead, we let V2 clients and servers be first-class citizens in the V3 world, then everyone is happy. Nova can require a domain token. Clients don't need to be rewritten just yet. Clouds need only be updated when they expose functionality that require V3 domain tokens (i.e. we must upgrade Nova & Keystone at the same time), but even then clients don't need to be rewritten. Clients _do_ need to be rewritten if/when they want to use V3 specific functionality e.g. logging in to a non-default domain.

This is why users have a default domain, right; so we don't force every client to learn about domains? If we do the same for unscoped = domain tokens, then V3 becomes compatible with V2. Puppies and babies rejoice.

[Dolph Mathews (dolph)]

> a domain-scoped token (a.k.a. unscoped token in my worldview)

Unscoped tokens don't carry authorization. A domain-scoped token carries some type of explicit authorization on the domain in the form of roles. How do you propose representing domain-level authorization that keystone hands out freely to every user?

> if I need a domain token for a particular Nova call

Other than for metering purposes, I'm not aware of any use cases for other OpenStack projects to become domain-aware. If there are any such discussions going on, I'd love to hear about them.

> This is why users have a default domain

User's don't have a default domain, but they have a default project ID.

[Adam Young (ayoung)]

No, domain and unscoped are two different things. Unscoped can be thought of as "scoped to this user" and should only be used for user level operations, or to get tokens more finely scoped. Domain scoped tokens should not be able to get project scoped tokens.