Reimplement LDAP support in Keystone

Bug #933852 reported by Adam Young on 2012-02-16
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Undecided
Adam Young

Bug Description

With the Merge of the Redux branch, Keystone lost its LDAP support.

Adam Young (ayoung) on 2012-02-16
Changed in keystone:
assignee: nobody → Adam Young (ayoung)
Adam Young (ayoung) wrote :

Current development is pushed to:

https://github.com/admiyo/keystone/tree/ldap3

Unit tests can either be run against the fakeldap implementation or a live server.

Unit tests against fakeldap pass except for

    test_create_duplicate_tenant_name_fails FAIL
    test_create_duplicate_user_id_fails FAIL
    test_create_duplicate_user_name_fails FAIL
    test_get_tenant_by_name ERROR
    test_rename_duplicate_tenant_name_fails FAIL
    test_rename_duplicate_user_name_fails FAIL

Tests against the live DB server pass except for
    test_create_duplicate_tenant_name_fails FAIL
    test_create_duplicate_user_id_fails FAIL
    test_create_duplicate_user_name_fails FAIL
    test_rename_duplicate_tenant_name_fails FAIL
    test_rename_duplicate_user_name_fails FAIL
    test_update_user_id_does_nothing FAIL

Changed in keystone:
status: New → In Progress
Adam Young (ayoung) wrote :
Download full text (4.2 KiB)

Here’s my set up and the design decisions I’ve made so far. Since this code is not yet submitted for code review, there is a good chance that it will change prior to deployment.

Users will be stored in a flat collection. ou=Users,$SUBTREE and be based on the standard LDAP objectClass inetOrgPerson which is defined in /etc/openldap/schema/inetorgperson.ldif. Currently, only two fields are used: cn and sn. cn is used for the bind call, and is the id field in the user object.

Tenants are in a collection that is a peer to Users. Tenants are instancs of the groupOfNames object class defined in /etc/openldap/schema/core.ldif. Tenant membership is indicated by the presence of the User’s DN in the tenant’s members attribute.

Roles are instances of the LDAP object class organizationalRole defined in /etc/openldap/schema/core.ldif. Role assignment is indicated by the presence of the User’s DN in the roleOccupant attribute.

Configuration of LDAP for the Keystone server is provided by the [LDAP] stanza in the appropriate keystone.conf file. Here are the supported values

    url
    user
    password
    suffix
    use_dumb_member
    user_tree_dn
    tenant_tree_dn
    role_tree_dn

And an example of what my config file looks like:
01 [ldap]
02 url = ldap://localhost
03 tree_dn = dc=younglogic,dc=com
04 user_tree_dn = dc=Users,dc=younglogic,dc=com
05 role_tree_dn = dc=Roles,dc=younglogic,dc=com
06 tenant_tree_dn = dc=Groups,dc=younglogic,dc=com
07 user = dc=Manager,dc=younglogic,dc=com
08 password = freeipa4all
09 backend_entities = ['Tenant', 'User', 'UserRoleAssociation', 'Role']
10 suffix =cn=younglogic,cn=com
11
12 [identity]
13 driver = keystone.identity.backends.ldap.Identity

Not all of these fields need to be specified. It is expected that the user will supply simply the suffix field, and not override the values of user_tree_dn,role_tree_dn, or tenant_tree_dn.

backend_entities is not currently honored. It is expected that LDAP will instead either manage all of these or non e of them, with token management handled by a different backend provider.

use_dumb_member is still honored from the previous incarnation, but has not been tested, nor do I understand the intention of this code.

The unit tests for the LDAP code use a common code sournce with the other Identity management backends. To run just the LDAP unit tests, from the Keystone directory, run
1 python ./run_tests.py test_backend_ldap

Additionally, the unit tests can be run against a live OpenLDAP server by running.
1 python ./run_tests.py _ldap_livetest

All tests pass successfully on my development machine as of this posting.

I’m running Fedora 16, which supports OpenLDAP. Specifically I am running openldap-servers-2.4.26-5.fc16.x86_64. To start the service, run
1 sudo service slapd start

To configure the server, I use a file I call manager.ldif:
01 dn: olcDatabase={2}hdb,cn=config
02 changetype: modify
03 replace: olcSuffix
04 olcSuffix: dc=younglogic,dc=com
05 -
06 replace: olcRootDN
07 olcRootDN: dc=Manager,dc=younglogic,dc=com
08 -
09 add: olcRootPW
10 olcRootPW: {SSHA}lBDIdfwvZkITal0k9tdhiCUolxpf6anu

You should modify the suffix for your organization.
Execute the c...

Read more...

Adam Young (ayoung) wrote :

Because I have rebased the commits, I've created another branch with the source:
https://github.com/admiyo/keystone/tree/ldap3

Adam Young (ayoung) wrote :

typo in the above config file sample. It should read

user_tree_dn = ou=Users,dc=younglogic,dc=com
role_tree_dn = ou=Roles,dc=younglogic,dc=com
tenant_tree_dn = ou=Groups,dc=younglogic,dc=com

ou, not cn

Fix proposed to branch: master
Review: https://review.openstack.org/4362

Reviewed: https://review.openstack.org/4362
Committed: http://github.com/openstack/keystone/commit/63437e9dca3b969c917fb138716aa4d3e5fabafa
Submitter: Jenkins
Branch: master

commit 63437e9dca3b969c917fb138716aa4d3e5fabafa
Author: Adam Young <email address hidden>
Date: Mon Feb 6 21:21:46 2012 -0500

    LDAP Identity backend

    Bug 933852

    Merged over the code from the legacy keystone implementation, updated
    style and streamlined the API a bit.

     * Unit tests can be run against a live OpenLDAP server
     * Password hashing done via passlib. Only does salted sha1, which is what simple_bind requires, but is not secure.
     * Added pip dependencies

    Change-Id: I5296d94f6b7d0a7c7dbc887cdae872171e34bb5f

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2012-02-29
Changed in keystone:
milestone: none → essex-4
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2012-04-05
Changed in keystone:
milestone: essex-4 → 2012.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers