Open Stack

On 04/24/2013 09:00 AM, Simo Sorce wrote:
> On Tue, 2013-04-23 at 15:26 -0700, Ryan Lane wrote:
>> <https://docs.google.com/file/d/0B96SIvDkZEUJU1JoZE8xTWh4UFk/edit?usp=sharing>
>>
>>
>> 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
>> hierarchy.
>>
> 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:
> [domain]
> 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.
>
> Simo.
>

I wrote up this blueprint in support of the "separate driver per domain" 
approach:

https://blueprints.launchpad.net/keystone/+spec/multiple-datastores

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:
https://blueprints.launchpad.net/keystone/+spec/json-for-ldap

Which is probably a dupe of:

https://blueprints.launchpad.net/keystone/+spec/ldap-object-templates

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.

https://review.openstack.org/#/c/18280/