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
