Hi Joe,
If I'm working across multiple tenants, I'd prefer one token that I can
securely handle that proves access rights to the tenants I'm working with.
Handling multiple tokens increases the complexity of clients needing to provide
multi-tenancy access to an authenticated identity. It also adds more calls to
keystone.
Again, I think that having the keystone reference implementation restrict
tokens to 1 tenant is fine. We shouldn't have such arbitrary restrictions in
the API contract though. It needs to be extensible and flexible to allow for
the all sorts of use cases that are likely to occur.
Thanks,
joe
-----Original Message-----
From: heckj [mailto:he...@mac.com]
Sent: Tuesday, November 13, 2012 3:59 PM
To: Joe Savak
Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net
(openstack@lists.launchpad.net)
Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing
authorization to projects/tenants in the Keystone V3 API
Hey Joe:
Currently a user scoped token doesn't include a service catalog - mostly
because I think the service catalog generally requires tenant_id's to
interpolate into the values to provide it. That doesn't mean we can't put
in/include service catalog endpoints where that value doesn't need to be
determined.
I'm also questioning the value of providing a token scoped to all tenants
associated with a user - that seems to have the same value as just using a user
token.
In fact, even if we allow some arbitrary set of tenants to be scoped into a
token along with a user, what on earth should be in the service catalog?
Endpoints relevant to every possible tenant?
This just seems to be a potential explosion of data that is poorly scoped from
a security perspective.
-joe
On Nov 13, 2012, at 1:42 PM, Joe Savak <joe.sa...@rackspace.com> wrote:
> Will user-scoped token include the full service catalog?
>
> Also, I thought the consensus was to allow the API contract to be flexible on
> how many tenants we can scope the token to. The ref impl can enforce 1
> tenant-scoped token. Are we diverging from this?
>
> Thanks,
> joe
>
> -----Original Message-----
> From: openstack-bounces+joe.savak=rackspace....@lists.launchpad.net
> [mailto:openstack-bounces+joe.savak=rackspace....@lists.launchpad.net] On
> Behalf Of heckj
> Sent: Tuesday, November 13, 2012 1:34 PM
> To: OpenStack Development Mailing List
> Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net)
> Subject: Re: [Openstack] [openstack-dev] Fwd: [keystone] Tokens representing
> authorization to projects/tenants in the Keystone V3 API
>
>
> On Nov 13, 2012, at 11:01 AM, Jorge Williams <jorge.willi...@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
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
