<font size=2 face="sans-serif">I'm a big -1 on having to resort to multiple
keystones to support multiple LDAPS for authentication.   Again this
is a separate issue from the 1 domain per ldap agreement.  Let's please
let Henry Nash investigate the multiple pluggable LDAPs for authentication
 like we  agreed to at the summit and not throw the baby out
with the bath water.</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br>
<br><font size=2 face="sans-serif">Brad </font>
<br><font size=2 face="sans-serif"><br>
Brad Topol, Ph.D.<br>
IBM Distinguished Engineer<br>
OpenStack<br>
(919) 543-0646<br>
Internet:  btopol@us.ibm.com<br>
Assistant: Cindy Willman (919) 268-5296</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Adam Young <ayoung@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">openstack-dev@lists.openstack.org</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">04/25/2013 06:30 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[keystone] Suggested LDAP DIT for domains</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 04/25/2013 11:08 AM, Bhandaru, Malini K wrote:<br>
> Multiple LDAPS may be insanity but wonder about a use case where company-X
and company-Y with their own respective LDAPs wants to use a public cloud.
 Or may be that is an external-auth type scenario (Keystone mentions
it) and as far as OpenStack/keystone concerned, can be agnostic of those
LDAPs and we are all set.<br>
<br>
Multiple Keystones, one per LDAP.  David Chadwick's solution also
<br>
addresses it. But we are not going to put them all behind a single <br>
Keystone.  Regardless, this is not the use cass we were solving below,
<br>
it was one LDAP with multiple domains.<br>
<br>
<br>
<br>
> Malini<br>
><br>
> -----Original Message-----<br>
> From: Adam Young [</font></tt><a href=mailto:ayoung@redhat.com><tt><font size=2>mailto:ayoung@redhat.com</font></tt></a><tt><font size=2>]<br>
> Sent: Thursday, April 25, 2013 7:46 AM<br>
> To: openstack-dev@lists.openstack.org<br>
> Subject: Re: [openstack-dev] [keystone] Suggested LDAP DIT for domains<br>
><br>
> OK,  so Ryan has convinced me that multiple LDAP servers under
the same Keystone is an incantation for self induced insanity.<br>
><br>
> Based on conversations with the other devs, we are going to enforce
that there is only one LDAP server per keystone, and limit the number of
domains it can support to one.<br>
><br>
> There can be only one.<br>
><br>
> The APIs for Domains will still be implemented, but creating or modifying
a domain will be return an Not implemented return code. There will be a
single domain object that will be immutable, although we may allow initializing
it from config file values.<br>
><br>
> Why are we "yanking" a feature like this? Quite simply,
because the vast majority of LDAP deployments out there will not use it,
and will not support the approach we have started.  We would rather
focus on solving the real needs of the LDAP users.  Most people cannot
write to their LDAP servers, and those that can often don't have the power
to change the schema.  Thus far, the LDAP work has kept this design
in mind, but Domains forced us to marry up two inconstant views of the
world.<br>
><br>
> Multiple domains will still be supported in the SQL backend.<br>
><br>
> Organizations that require multiple LDAP servers were not served by
the existing implementation.  Those will require a different solution.
Each will get their own Keystone server, and we will use the approach sketched
out in other blueprints to ensure that they can co-exist in a single Open
Stack deployment.<br>
><br>
><br>
><br>
> On 04/24/2013 10:46 AM, Adam Young wrote:<br>
>> On 04/24/2013 09:00 AM, Simo Sorce wrote:<br>
>>> On Tue, 2013-04-23 at 15:26 -0700, Ryan Lane wrote:<br>
>>>> <</font></tt><a href=https://docs.google.com/file/d/0B96SIvDkZEUJU1JoZE8xTWh4UFk/edit?us><tt><font size=2>https://docs.google.com/file/d/0B96SIvDkZEUJU1JoZE8xTWh4UFk/edit?us</font></tt></a><tt><font size=2><br>
>>>> p=sharing><br>
>>>><br>
>>>><br>
>>>><br>
>>>> In the above, everything exists under ou=domains. In the
case an<br>
>>>> operator wants to use only one single (default) domain,
they'd set<br>
>>>> their configuration to use the root, rather than ou=domains,
and<br>
>>>> would move everything up a level. Otherwise, a default
domain exists<br>
>>>> as a normal domain in the tree.<br>
>>>><br>
>>>><br>
>>>> In this DIT configuration, domains have roles and projects,
projects<br>
>>>> have roles. Projects and roles have members. I believe
there was<br>
>>>> discussion of implying membership in the project by membership
of<br>
>>>> the roles. I'm not a huge fan of that, but I can modify
this design<br>
>>>> if that's the preferred approach.<br>
>>>><br>
>>>><br>
>>>> There's some major benefits of designing the DIT in this
way:<br>
>>>><br>
>>>><br>
>>>> 1. It's possible to scope searches by depth and base to
limit<br>
>>>> searches to domains and project and to find roles for
domains and projects.<br>
>>>> 2. The DIT can be extended by LDAP administrators for
other uses. I<br>
>>>> can give you a ton of examples, as I'm doing this currently
for<br>
>>>> per-project sudoers, service and group users, etc..<br>
>>>> 3. Users, groups, and projects have no requirements for
being<br>
>>>> globally unique. They are only unique per domain.<br>
>>>> 4. For operators using the current implementation who
don't want<br>
>>>> multiple domains, this is backwards compatible.<br>
>>>> 5. For operators wanting to using multiple domains, they
simply need<br>
>>>> to move their tree a level deeper. Of course this isn't
a simple<br>
>>>> change, but it should be a matter of configuration for
their<br>
>>>> applications, rather than development effort.<br>
>>>> 6. Domains are a matter of hierarchy, and this uses LDAP's
natural<br>
>>>> hierarchy.<br>
>>>><br>
>>> It would be nice if this hierarchy were optional, for example
you may<br>
>>> have attributes with substitution rules that tell where the
base for<br>
>>> a domain is<br>
>>><br>
>>> Pseudo ini-style config:<br>
>>> [domain]<br>
>>> base = ou=%D,ou=domains<br>
>>><br>
>>> where %D is substituted with the domain name.<br>
>>><br>
>>><br>
>>> This would allow people to flexibly define their DITs.<br>
>>><br>
>>> Another option could be to spawn a separate driver per domain
with a<br>
>>> template based configuration system (based again on substitutions),<br>
>>> or a per domain explicit configuration.<br>
>>> This way you could use either one or multiple LDAP servers
at the<br>
>>> same time as each domain could have a completely different
configuration.<br>
>>><br>
>>> Simo.<br>
>>><br>
>> I wrote up this blueprint in support of the "separate driver
per<br>
>> domain" approach:<br>
>><br>
>> </font></tt><a href="https://blueprints.launchpad.net/keystone/+spec/multiple-datastores"><tt><font size=2>https://blueprints.launchpad.net/keystone/+spec/multiple-datastores</font></tt></a><tt><font size=2><br>
>><br>
>> Which gives us a way to register the drivers.  What it does
not give<br>
>> us is a domain registry.  I suspect that the right way to
do a domain<br>
>> registry would be to use a either a flat file driver or the SQL
Driver<br>
>> as the Identity driver, and have a way to link to other drivers
for<br>
>> the individual domains.  We could also put a domains section
into the<br>
>> config file, with a mapping of domain-id to driver, but that misses<br>
>> all of the configuration options for each domain.<br>
>><br>
>> I also started this blueprint for extracting the binding information<br>
>> from the config file for LDAP:<br>
>> </font></tt><a href="https://blueprints.launchpad.net/keystone/+spec/json-for-ldap"><tt><font size=2>https://blueprints.launchpad.net/keystone/+spec/json-for-ldap</font></tt></a><tt><font size=2><br>
>><br>
>> Which is probably a dupe of:<br>
>><br>
>> </font></tt><a href="https://blueprints.launchpad.net/keystone/+spec/ldap-object-templates"><tt><font size=2>https://blueprints.launchpad.net/keystone/+spec/ldap-object-templates</font></tt></a><tt><font size=2><br>
>><br>
>> So we are thinking along the same ideas.<br>
>><br>
>> However, David Chadwick's attribute mapping approach might be
a better<br>
>> solution for complex mappings from LDAP.  Kristy Siu had
submitted it<br>
>> back in decebmer, but it got nacked and abandoned.<br>
>><br>
>> </font></tt><a href=https://review.openstack.org/#/c/18280/><tt><font size=2>https://review.openstack.org/#/c/18280/</font></tt></a><tt><font size=2><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> OpenStack-dev@lists.openstack.org<br>
>> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
<br>
</font></tt>
<br>