I'm a bit confused as to how Keystone will handle authorization. It sounds now like it is only handling authentication. Can you clarify?
Devin On Jul 13, 2011, at 9:41 PM, Ziad Sawalha wrote: > We've taken much of that out of the current API; so the API does not allow > creating these entities through the service API. > > And we don't have delegation over tenant administration either, although > the API we have in place can fully support atier that implements itÅ . > > Z > > On 7/13/11 11:30 AM, "Bryan Taylor" <btay...@rackspace.com> wrote: > >> How is this different in effect than letting swift or nova be tenants? >> Each tenant gets to define users, roles, and groups, right? >> >> On 07/13/2011 10:39 AM, Jay Pipes wrote: >>> On Wed, Jul 13, 2011 at 12:45 AM, Ziad Sawalha >>> <ziad.sawa...@rackspace.com> wrote: >>>> Here's a possible use case we can implement to address this: >>>> >>>> A service 'registers' itself with Keystone and reserves a name (Ex. >>>> Swift, >>>> or nova). Keystone will guarantee uniqueness. >>>> Registered services can then create roles for the service (Ex. >>>> swift:admin >>>> or nova:netadmin) or tuples as suggested below (nova:delete:volume) >>>> On token validation, Keystone returns these roles and a service can >>>> apply >>>> it's own policies based on them. >>>> >>>> This is super-simplified and we can expand on it. >>>> Other benefits: >>>> >>>> Registration would also be handy to allow services to add and manage >>>> endpoints as well. >>>> We can also tie this with the concept of a ClientID so services can >>>> identify >>>> themselves as well with a long-lived token >>>> (see https://github.com/rackspace/keystone/issues/84) >>>> Common names for services could be implemented as shareable among >>>> different >>>> implementations (Ex: compute:admin) >>>> >>>> Thoughts? >>> >>> Sounds like a very reasonable approach to me. >>> >>>> And comments inline ZNS>> >>> >>> Hehe, you guys need a better mail client ;) >>> >>> -jay >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> This email may include confidential information. If you received it in >> error, please delete it. >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > This email may include confidential information. If you received it in error, > please delete it. > > > _______________________________________________ > 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