Open Stack

+1  from me as well!  (Catching up with all the notes on this)

Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  btopol at us.ibm.com
Assistant: Cindy Willman (919) 268-5296



From:   "Yee, Guang" <guang.yee at hp.com>
To:     OpenStack Development Mailing List 
<openstack-dev at lists.openstack.org>
Date:   04/25/2013 10:48 PM
Subject:        Re: [openstack-dev] [keystone] Suggested LDAP DIT for 
domains



Well said Henry.


Guang


-----Original Message-----
From: Henry Nash [mailto:henryn at linux.vnet.ibm.com] 
Sent: Thursday, April 25, 2013 4:31 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Suggested LDAP DIT for domains

So I think we do have to be careful what we say here.  I think the thing 
we
have discussed most so far is the issue of trying to store our 
multi-domain
model structure in one LDAP backend.  I think the general consensus is 
that
this isn't a good thing.  However, I don't believe it necessary follows 
that
we need multiple keystones if you have more than one domain using LDAP. 

For instance, imagine we modify keystone so that:
a) We separate authentication from authorization as we have discussed at 
the
summit, so that each can use their own methods
b) We separate our domain storage (i.e. where we store the list of domains
and they configuration)  from both of the above
c)  Each domain can chose its own type of authn/z - and where these 
service
are to found

Such a structure would allow a number of options
i) Each domain to have its own authn/z, either locally or remote (e.g. use
my company's LDAP server for authn, but a local, shared SQL for authz) all
controlled by a single keystone
ii) The domain CRUD to be managed by one keystone, but a remote keystone
handle the responses for a given domain
iii) Each domain could utilize something the attribute mapping 
functionality
from the Kent Federation work as the engine to provide a mapping from the
remote Identity Provider into the authz roles that OS needs 
iv) All the domains could still use a common backend instance & methodolgy
(i.e. the current state), provided such a backend has the logical 
structure
to allow it (e.g. if your LDAP really did have multiple user-sets, then 
each
domain would be configured to point at the appropriate one - but none of
them would be cognisant of the others - an we would not store the domain
structure in the LDAP)

The above is a summary of the blueprint I am trying to write up on
domain-specific-backends, following the summit.

Henry

On 25 Apr 2013, at 16:52, Adam Young wrote:

> On 04/25/2013 11:08 AM, Bhandaru, Malini K wrote:
>> 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.
> 
> Multiple Keystones, one per LDAP.  David Chadwick's solution also
addresses it. But we are not going to put them all behind a single 
Keystone.
Regardless, this is not the use cass we were solving below, it was one 
LDAP
with multiple domains.
> 
> 
> 
>> Malini
>> 
>> -----Original Message-----
>> From: Adam Young [mailto:ayoung at redhat.com]
>> Sent: Thursday, April 25, 2013 7:46 AM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [keystone] Suggested LDAP DIT for domains
>> 
>> OK,  so Ryan has convinced me that multiple LDAP servers under the same
Keystone is an incantation for self induced insanity.
>> 
>> 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.
>> 
>> There can be only one.
>> 
>> 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.
>> 
>> 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.
>> 
>> Multiple domains will still be supported in the SQL backend.
>> 
>> 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.
>> 
>> 
>> 
>> On 04/24/2013 10:46 AM, Adam Young wrote:
>>> 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?us
>>>>> p=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/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[attachment "smime.p7s" deleted by Brad Topol/Raleigh/IBM] 
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130426/8086474c/attachment.html>