Open Stack

On Nov 13, 2012, at 11:01 AM, Jorge Williams <jorge.williams at rackspace.com> wrote:
> On Nov 13, 2012, at 11:35 AM, heckj wrote:
>> So maintaining a token scoped to just the user, and a mechanism to scope it to a tenant sound like all goodness. We can absolutely keep the API such that it can provide either. 
>> 
>> Right now, our auth_token middleware implicitly requires a tenant in that scoping to work. If someone wanted to support a token scoped to just a user for the services, they'd need a different middleware there. Keystone as a service *doesn't* use the auth_token middleware, so with the V3 API we can make it provide services appropriately based on a token scoped only to the user.
>> 
>> All that in place, allow a token to be indeterminate scoped to multiple tenants is fraught with security flaws, and if we continue to provide unscoped tokens, that should obviate the need for token scoped to multiple tenants. 
> 
> I'm not sure I'm following you there.  I don't see how unscoped tokens obviate the need to scope to multiple tenants, these may be driven by  different concerns. 
> 
> Again, I think we need to have some flexibility in how we scope tokens. The API should be flexible enough to support different models -- I think that scoping a token to multiple tenants is useful in cases such as delegation -- where a single identity may be issued revokable access to a set of resources in multiple projects.

The consensus from the folks weighing in on this from a security perspective seems to be that it's kosher to restrict tokens further (the least privilege thing). Broadening the scope to multiple tenants or sets of tenants doesn't appear to follow those best practices. If you wanted to accept a less-scoped token than the scoped to single tenant, you can accept and use a user-scoped token, at least by my read.

-joe