Open Stack

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.sawalha at 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 <thor at wolpert.ca>
> Date: Wed, 13 Jul 2011 17:17:03 -0700
> To: Ziad Sawalha <ziad.sawalha at rackspace.com>
> Cc: Jay Pipes <jaypipes at gmail.com>, Bryan Taylor <btaylor at rackspace.com>,
> "openstack at lists.launchpad.net" <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>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> wrote:
>>
>> >On Wed, Jul 13, 2011 at 12:30 PM, Bryan Taylor <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
>> >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
>> 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/ef80205f/attachment.html>