[openstack-dev] [keystone] Suggested LDAP DIT for domains

Brad Topol btopol at us.ibm.com
Sun Apr 28 13:59:37 UTC 2013

I need to go read Henry's  document. I can't comment on that yet.  In 
principle, I am OK with having a separate json config file for doing the 
LDAP configuration.  I agree that we will be adding enough content here 
that its probably best to move it out of keystone.conf.   We do however 
need to look at the config options apache provides for this as we will 
benefit from its experience.  For the chain of domains work I'm pretty 
sure I can get you some stakeholders and use cases.   We definitely have 
folks interested in getting multiple keystones to work together. Starting 
the planning/design of this work has the best chance of being 
successful/providing value if we get the stakeholders and concrete use 
cases first and then go from there.



Brad Topol, Ph.D.
IBM Distinguished Engineer
(919) 543-0646
Internet:  btopol at us.ibm.com
Assistant: Cindy Willman (919) 268-5296

From:   Adam Young <ayoung at redhat.com>
To:     openstack-dev at lists.openstack.org
Date:   04/26/2013 05:25 PM
Subject:        Re: [openstack-dev] [keystone] Suggested LDAP DIT for 

OK, so Henry's document, while sound, it actually specifies a schema. 
It is what a sane person would do, but LDAP drives away sanity.  We know 
that for most people, wae can't dictate what the schema would look like.
So, if there is a need for "manging multiple domains from a single 
Backend" we will try to migrate over to useing Henry's design.  It was 
what I wanted in the first place.

If there is a customer out there that wants to use LDAP with a schema 
that matches Henry's design, we still have to account for the fact that 
not everything under a single root can be considered a domain.  There 
may be no root entity, or there might be things under their root entity 
that is not a domain, but that still implements orgUnit.

Make that one reason in support of the external JSON config for domains.

Lets look at the requirement that  a single Keystone front multiple LDAP 
servers.  These are not going to be dynamically definied. It is going to 
be a small, fixed  number of LDAP servers, with one being added or 
removed on average of every couple of years.  We need a place to 
configure these.

That is two reasons in support of an external JSON config file

Now, lets take the case where two organizations have one cloud, but they 
want to maintain their user data completely separately. Different LDAP 
server, different Token database, and maybe even an overlapping but 
different set of endpoints.  These two Keystone servers need a way to 
talk to each other.  Each gets registered as an "external" domain in the 
JSON file.

Hence:  https://etherpad.openstack.org/chain-of-domains

Its clean.  It is straightforward, and it allows the backends to 
interoperate.  If we decide to cut some aspect of scope, it still 
supports the other use cases.

We probably want to discuss it in context with



OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130428/4f5623a4/attachment.html>

More information about the OpenStack-dev mailing list