[openstack-dev] [keystone] Suggested LDAP DIT for domains
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
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
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
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...
More information about the OpenStack-dev