To make it perfectly clear: We are NOT removing nor plan to remove the ability 
to use LDAP for users and groups in Keystone.

NOTE: Please be sure to read the whole email AND FAQ before worrying about the 
impact of this deprecation.

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. 

Now before anyone starts worrying about this please read the whole email and 
FAQ at the end. Let me be perfectly clear. LDAP assignment is *not*  referring 
to using LDAP for user and groups. That highly popular feature remains in 
Keystone.This change should have no impact for other users of LDAP in Keystone.

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).

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.


Q: Will Keystone still support Users and Groups in LDAP?
A: Absolutely! There are no plans to deprecate utilizing LDAP (or Active 
Directory) to store users and groups. The Keystone team is committed to 
maintaining and improving the LDAP Identity driver.

Q: Will there be a migration from LDAP Assignment to SQL Assignment for the 
deployers that are still using LDAP Assignment backend?
A: Each deployment is highly specific to the LDAP data store used and schema 
defined by the organization. The Keystone team has spoken with the deployers 
that have stated they are using LDAP Assignment (and plan to move to SQL 
assignment). Most deployers using LDAP Assignment already have plans on how to 
Migrate. The Keystone team will be happy to provide advice (come chat with us 
in #openstack-keystone on Freenode) but we do not expect to provide a canned 
script to make the migration happen.

Q: Why not just keep Assignment in LDAP as an option, but freeze it like the V2 
A: We explored this option, but with all of the new functionality (including 
identity federation), code fixes, and maintenance issues, it just doesn’t make 
sense from a cloud-interoperability standpoint to maintain a second-class [at 
best barely implementing feature parity] driver for Assignment. We would rather 
support a clear interoperable OpenStack world where a user doesn’t need to 
guess / know a ton about the deployment to successfully utilize the cloud 

Thanks for reading through the whole email! Please feel free to chat with the 
development team on IRC or via the Mailing List to discuss any other issues / 
concerns  related to this change.

Morgan Fainberg
Keystone PTL

OpenStack Development Mailing List (not for usage questions)

Reply via email to