[openstack-dev] [keystone] Suggested LDAP DIT for domains
ayoung at redhat.com
Wed Apr 24 14:46:08 UTC 2013
On 04/24/2013 09:00 AM, Simo Sorce wrote:
> On Tue, 2013-04-23 at 15:26 -0700, Ryan Lane wrote:
>> In the above, everything exists under ou=domains. In the case an
>> operator wants to use only one single (default) domain, they'd set
>> their configuration to use the root, rather than ou=domains, and would
>> move everything up a level. Otherwise, a default domain exists as a
>> normal domain in the tree.
>> In this DIT configuration, domains have roles and projects, projects
>> have roles. Projects and roles have members. I believe there was
>> discussion of implying membership in the project by membership of the
>> roles. I'm not a huge fan of that, but I can modify this design if
>> that's the preferred approach.
>> There's some major benefits of designing the DIT in this way:
>> 1. It's possible to scope searches by depth and base to limit searches
>> to domains and project and to find roles for domains and projects.
>> 2. The DIT can be extended by LDAP administrators for other uses. I
>> can give you a ton of examples, as I'm doing this currently for
>> per-project sudoers, service and group users, etc..
>> 3. Users, groups, and projects have no requirements for being globally
>> unique. They are only unique per domain.
>> 4. For operators using the current implementation who don't want
>> multiple domains, this is backwards compatible.
>> 5. For operators wanting to using multiple domains, they simply need
>> to move their tree a level deeper. Of course this isn't a simple
>> change, but it should be a matter of configuration for their
>> applications, rather than development effort.
>> 6. Domains are a matter of hierarchy, and this uses LDAP's natural
> It would be nice if this hierarchy were optional, for example you may
> have attributes with substitution rules that tell where the base for a
> domain is
> Pseudo ini-style config:
> base = ou=%D,ou=domains
> where %D is substituted with the domain name.
> This would allow people to flexibly define their DITs.
> Another option could be to spawn a separate driver per domain with a
> template based configuration system (based again on substitutions), or a
> per domain explicit configuration.
> This way you could use either one or multiple LDAP servers at the same
> time as each domain could have a completely different configuration.
I wrote up this blueprint in support of the "separate driver per domain"
Which gives us a way to register the drivers. What it does not give us
is a domain registry. I suspect that the right way to do a domain
registry would be to use a either a flat file driver or the SQL Driver
as the Identity driver, and have a way to link to other drivers for the
individual domains. We could also put a domains section into the config
file, with a mapping of domain-id to driver, but that misses all of the
configuration options for each domain.
I also started this blueprint for extracting the binding information
from the config file for LDAP:
Which is probably a dupe of:
So we are thinking along the same ideas.
However, David Chadwick's attribute mapping approach might be a better
solution for complex mappings from LDAP. Kristy Siu had submitted it
back in decebmer, but it got nacked and abandoned.
More information about the OpenStack-dev