Any thoughts on pulling in OpenDS or OpenLDAP? A plus for OpenDS is it'a already integrated with OpenAM and could supply federated logins if so desired. I have that need.
On Sat, Jul 16, 2011 at 3:56 PM, Ziad Sawalha <ziad.sawa...@rackspace.com>wrote: > 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 <t...@wolpert.ca> > Date: Wed, 13 Jul 2011 17:17:03 -0700 > To: Ziad Sawalha <ziad.sawa...@rackspace.com> > Cc: Jay Pipes <jaypi...@gmail.com>, Bryan Taylor <btay...@rackspace.com>, > "openstack@lists.launchpad.net" <openstack@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.sawa...@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" <jaypi...@gmail.com> wrote: >> >> >On Wed, Jul 13, 2011 at 12:30 PM, 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? >> > >> >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@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
