Open Stack

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.

-- 
Simo Sorce * Red Hat, Inc * New York