<font size=2 face="sans-serif">+1  from me as well!  (Catching
up with all the notes on this)</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">"Yee, Guang"
<guang.yee@hp.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">OpenStack Development
Mailing List <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 10:48 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>Well said Henry.<br>
<br>
<br>
Guang<br>
<br>
<br>
-----Original Message-----<br>
From: Henry Nash [</font></tt><a href=mailto:henryn@linux.vnet.ibm.com><tt><font size=2>mailto:henryn@linux.vnet.ibm.com</font></tt></a><tt><font size=2>]
<br>
Sent: Thursday, April 25, 2013 4:31 PM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] [keystone] Suggested LDAP DIT for domains<br>
<br>
So I think we do have to be careful what we say here.  I think the
thing we<br>
have discussed most so far is the issue of trying to store our multi-domain<br>
model structure in one LDAP backend.  I think the general consensus
is that<br>
this isn't a good thing.  However, I don't believe it necessary follows
that<br>
we need multiple keystones if you have more than one domain using LDAP.
 <br>
<br>
For instance, imagine we modify keystone so that:<br>
a) We separate authentication from authorization as we have discussed at
the<br>
summit, so that each can use their own methods<br>
b) We separate our domain storage (i.e. where we store the list of domains<br>
and they configuration)  from both of the above<br>
c)  Each domain can chose its own type of authn/z - and where these
service<br>
are to found<br>
<br>
Such a structure would allow a number of options<br>
i) Each domain to have its own authn/z, either locally or remote (e.g.
use<br>
my company's LDAP server for authn, but a local, shared SQL for authz)
all<br>
controlled by a single keystone<br>
ii) The domain CRUD to be managed by one keystone, but a remote keystone<br>
handle the responses for a given domain<br>
iii) Each domain could utilize something the attribute mapping functionality<br>
from the Kent Federation work as the engine to provide a mapping from the<br>
remote Identity Provider into the authz roles that OS needs <br>
iv) All the domains could still use a common backend instance & methodolgy<br>
(i.e. the current state), provided such a backend has the logical structure<br>
to allow it (e.g. if your LDAP really did have multiple user-sets, then
each<br>
domain would be configured to point at the appropriate one - but none of<br>
them would be cognisant of the others - an we would not store the domain<br>
structure in the LDAP)<br>
<br>
The above is a summary of the blueprint I am trying to write up on<br>
domain-specific-backends, following the summit.<br>
<br>
Henry<br>
<br>
On 25 Apr 2013, at 16:52, Adam Young wrote:<br>
<br>
> On 04/25/2013 11:08 AM, Bhandaru, Malini K wrote:<br>
>> Multiple LDAPS may be insanity but wonder about a use case where<br>
company-X and company-Y with their own respective LDAPs wants to use a<br>
public cloud.  Or may be that is an external-auth type scenario (Keystone<br>
mentions it) and as far as OpenStack/keystone concerned, can be agnostic
of<br>
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 Keystone.<br>
Regardless, this is not the use cass we were solving below, it was one
LDAP<br>
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<br>
Keystone is an incantation for self induced insanity.<br>
>> <br>
>> Based on conversations with the other devs, we are going to enforce
that<br>
there is only one LDAP server per keystone, and limit the number of domains<br>
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<br>
a domain will be return an Not implemented return code. There will be a<br>
single domain object that will be immutable, although we may allow<br>
initializing it from config file values.<br>
>> <br>
>> Why are we "yanking" a feature like this? Quite simply,
because the vast<br>
majority of LDAP deployments out there will not use it, and will not support<br>
the approach we have started.  We would rather focus on solving the
real<br>
needs of the LDAP users.  Most people cannot write to their LDAP servers,<br>
and those that can often don't have the power to change the schema.  Thus<br>
far, the LDAP work has kept this design in mind, but Domains forced us
to<br>
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<br>
existing implementation.  Those will require a different solution.
Each will<br>
get their own Keystone server, and we will use the approach sketched out
in<br>
other blueprints to ensure that they can co-exist in a single Open Stack<br>
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<br>
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<br>
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>
<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>
[attachment "smime.p7s" deleted by Brad Topol/Raleigh/IBM] _______________________________________________<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>
</font></tt>
<br>