Open Stack

Whatever name a container for global objects has - or if one or more even exist – is only relevant to a specific implementation and not canonical. It fits better as a configuration than as a core part of the API or code. Even in the same LDAP system, an operator may have their own unique implementation. Take, as an example, Active Directory with it's default setup. Some enterprises may use the BuiltIn container where 'global' entities live. Others may use the Users container. And some may create their own containers or OU. Some may want to map role assignments to group membership in certain groups (ex. If a user is a member of Domain Admins, have Keystone report them as having the keystone:admin role).

I posit that a construct like a 'global' tenant is artificial and not driven from a generic, canonical use case. It is actually not a tenant. And by adopting it we assume the risk of a collision with a backend that defines a 'global' tenant with a different semantic and we don't get much return for that risk.

I agree we should provide an out-of-the-box reference implementation, but we should keep Keystone acting as a metasystem that allows mapping the OpenStack use cases back to any operator implementation.

Look for an an LDAP implementation to come very soon … and we should pick the thread back up with more concrete examples?

Kind regards,
Z


From: Thor Wolpert <thor at wolpert.ca<mailto:thor at wolpert.ca>>
Date: Wed, 13 Jul 2011 17:17:03 -0700
To: Ziad Sawalha <ziad.sawalha at rackspace.com<mailto:ziad.sawalha at rackspace.com>>
Cc: Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>>, Bryan Taylor <btaylor at rackspace.com<mailto:btaylor at rackspace.com>>, "openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal

If they had called it "global" or some other container name, would you be happier with that?  If you're trying to leverage some LDAP style framework, then you'd always want users in some container instead of at the raw root.

Maybe some guidance or default schema would help those groups out?


On Wed, Jul 13, 2011 at 2:12 PM, Ziad Sawalha <ziad.sawalha at rackspace.com<mailto:ziad.sawalha at rackspace.com>> wrote:
And some current Nova users have created 'dummy' tenants to house global
users. That's ugly and hard to maintain, so we wanted to avoid 'dummy'
tenant solutions if possible. Given we're creating the spec right here and
now, we can do that :-)



On 7/13/11 12:14 PM, "Jay Pipes" <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:

>On Wed, Jul 13, 2011 at 12:30 PM, Bryan Taylor <btaylor at rackspace.com<mailto:btaylor at 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?
>
>A service can have multiple tenants. For instance, an installation of
>Nova might have a RAX tenant and a RAX-INTERNAL tenant, both of which
>can create users and roles separately. Keystone can manage these sets
>of users independently, but when the Nova service requests information
>from Keystone, supplying the tenant and user, which depending on the
>information stored in Keystone, could return different role/group
>infomation.
>
>-jay
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack at lists.launchpad.net<mailto:openstack at 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 at lists.launchpad.net<mailto:openstack at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110716/76e2ea29/attachment.html>