ldap Identity backend TenantAPI bugs

[Derek Yarnell]

There are two issues with the TenantAPI for the ldap Identity.

There is a mistaken attribute_mapping entry, which was mapping 'description' into 'desc'. Per RFC 2256 there should be no need to map this as the attribute as it is already 'description' in the LDAP schema. I am not aware of any other schema that would use 'desc' attribute for a 'groupOfNames' object.

Since there is no support (yet) for users, tenants or roles to be enabled/disabled there needs to be a attribute_ignore set for the 'enabled' attribute.

Attached is a diff of the changes.

[Adam Young (ayoung)]

I've tested the changes and they look good and work.

I'll post a patch to gerrit. Please contact me with the appropriate values to put in as the patch author.

[Adam Young (ayoung)]

Gerrit change
https://review.openstack.org/#/c/6523/

[Boden R (boden)]

Running with the latest Keystone code (Sept 10, 2012) I ran into the following issue:

# keystone tenant-create --name=admin
An unexpected error prevented the server from fulfilling your request.
{'info': 'enabled: attribute type undefined', 'desc': 'Undefined attribute
type'} (HTTP 500)

Which is described on the list here: https://lists.launchpad.net/openstack/msg16449.html

I manually applied the patch attached to this defect and both the 'desc' and 'enabled' issues went away. However the actual LDAP entry for the tenant does not have an attribute used to track the 'enabled' property of the tenant. Therefore I think it would be beneficial to try and find a different way of including the 'enabled' property of a tenant in LDAP without having to modify the schema...

I'm not an LDAP expert but could we use the 'seeAlso' attribute to point to a different entry which (optionally) tracks the enabled flag, or maybe the enabled value can be encoded in the actual description and parsed out...

Finally -- I'm hoping this defect can get fixed in the folsom time-frame, otherwise out of the box ldap support is painful.

Thanks

[Boden R (boden)]

Another update...

I ran into some issues with create_user as well when using the LDAP driver... Although I don't have the output handy is was related to invalid 'email' attribute which gets passed down on the REST API when you create a user and specify an --email..

To fix it I updated the UserApi class to look like this (so the email is mapped to mail):

    attribute_mapping = {'password': 'userPassword',
                         'email': 'mail',
                         'name': 'sn'}

Also I ran into an issue when creating tenants. The tenant Id comes in as 'tenantId' these days via the REST API so I added it to the attribute_ignore list in the UserApi class:

    attribute_ignore = ['tenantId', 'enabled', 'tenants']

I'm sure my changes are not 'production ready' but they got me working.

Thx

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/12752
Committed: http://github.com/openstack/keystone/commit/2c29d4ca4bd841823aa57e0cea7e97d5c2854581
Submitter: Jenkins
Branch: master

commit 2c29d4ca4bd841823aa57e0cea7e97d5c2854581
Author: Derek Yarnell <email address hidden>
Date: Mon Sep 10 20:52:14 2012 -0400

    LDAP backend attribute fixes

    R Boden and Adam Young assissted on this patch.

    There are two issues with the TenantAPI for the ldap Identity.

    There is a mistaken attribute_mapping entry, which was mapping
    'description' into 'desc'. Per RFC 2256 there should be no need to map
    this as the attribute as it is already 'description' in the LDAP
    schema. I am not aware of any other schema that would use 'desc'
    attribute for a 'groupOfNames' object.

    Since there is no support (yet) for users, tenants or roles to be
    enabled/disabled there needs to be a attribute_ignore set for the
    'enabled' attribute.

    Bug 980085

    Change-Id: I40afa7a1345c45c119e699bf4fd4c99652f66c2f