Open Stack

Hello.

On Wed Jan 28 2015 at 11:30:43 PM Morgan Fainberg <morgan.fainberg at gmail.com>
wrote:

> LDAP is used in Keystone as a backend for both the Identity (Users and
> groups) and assignments (assigning roles to users) backend.
>
> Where did the LDAP Assignment backend come from? We originally had a
> single backend for Identity (users, groups, etc) and Assignment
> (Projects/Tenants, Domains, Roles, and everything else
> not-users-and-groups). When we did the split of Identity and Assignment we
> needed to support the organizations that deployed everything in the LDAP
> backend. This required both a driver for Identity and Assignment.
>
>  We are planning on keeping support for identity while deprecating support
> for assignment.  There is only one known organization that this will impact
> (CERN) and they have a transition plan in place already.


I can (or actually can't do it here) name quite a few of our customers who
do use LDAP assignment backend. The issue that is solved by this is data
replication across data centers. What would be the proposed solution for
them? MySQL multi-master replication (Galera) is feared to perform badly
across DC.

The Problem
> ——————
> The SQL Assignment backend has become significantly more feature rich and
> due to the limitations of the basic LDAP schemas available (most LDAP
> admins wont let someone load custom schemas), the LDAP assignment backend
> has languished and fallen further and further behind. It turns out almost
> no deployments use LDAP to house projects/tenants, domains, roles, etc. A
> lot of deployments use LDAP for users and groups.
>
> We explored many options on this front and it boiled down to three:
>
> 1. Try and figure out how to wedge all the new features into a sub-optimal
> data store (basic/standard LDAP schemas)
> 2. Create a custom schema for LDAP Assignment. This would require
> convincing LDAP admins (or Active Directory admins) to load a custom
> schema. This also was a very large amount of work for a very small
> deployment base.
> 3. Deprecate the LDAP Assignment backend and work with the community to
> support (if desired) an out-of-tree LDAP driver (supported by those who
> need it).
>

I'd like to note that it is in fact possible to make LDAP backend work even
with native AD schema without modifications. The only issue that has been
hanging with LDAP schema from the very beginning of LDAP driver is usage of
groupOfNames for projects and nesting other objects under it. With some
fixes we managed to make it work with stock AD schema with no modifications
for Havana and port that to Icehouse.

Based upon interest, workload, and general maintainability issues, we have
> opted to deprecate the LDAP Assignment backend. What does this mean?
>

> 1. This means effective as of Kilo, the LDAP assignment backend is
> deprecated and Frozen.
> 1.a. No new code/features will be added to the LDAP Assignment backend.
> 1.b. Only exception to 1.a is security-related fixes.
>
> 2.The LDAP Assignment backend ("[assignment]/driver” config option set to
> “keystone.assignment.backends.ldap.Assignment” or a subclass) will remain
> in-tree with plans to be removed in the “M”-release.
> 2.a. This is subject to support beyond the “M”-release based upon what the
> keystone development team and community require.
>

Is there a possibility that this decision will be amended if someone steps
up to properly maintain LDAP backend? Developing such driver out of main
tree would be really hard mostly "catch up with mainline" work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150129/2efec00a/attachment.html>