LDAP backend lacks support for user_description_attribute mapping

[Rudolf Vriend]

The LDAP backend supports mapping between LDAP and keystone user attributes via the 'user_<attribute_name>_attribute' settings in the ldap driver configuration.

The implementation is incomplete, since there is no support for specifying a 'user_description_attribute' setting.

As long as the LDAP attribute name is 'description', one could specify a 1:1 'user_additional_attribute_mapping = description:description' mapping as a workaround, which would yield the desired result.

In case a users full name is stored in a different attribute (as with many AD backends where the users full name is contained in the 'displayName' attribute) there is no way to specify this mapping and results in users having no description.

[OpenStack Infra (hudson-openstack)]

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

[Steve Martinelli (stevemar)]

The description can be included by setting the "user_additional_attribute_mapping" in the [ldap] section of the config.

[ldap]
user_additional_attribute_mapping="ldap_description_attr_name:description"

I'm not sure how often description is used for the user API, so I'll mark this as wishlist for now since there is a work around

[Rudolf Vriend (rudolf-vriend-deactivatedaccount)]

No. Unfortunatily that doesn't work.

The user_additional_attribute_mapping (self.extra_attr_mapping) is ignored in the attribute mapping code after a LDAP get operation. Except for the 'special' case where 'description' is mapped to 'description' due to the attribute_mapping..get(k, k) (see https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L1359).

Since the user_additional_attribute_mapping seems to be only evaluated during LDAP create (https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L1433) which has been deprecated, I think it does make sense that either a user_description_attribute config is supported or the user_additional_attribute_mapping is evaluated after LDAP get operations.

For our use-cases a user.description is definitely a need to have, since user name & email aren't necessarily very expressive.

see also: https://bugs.launchpad.net/keystone/+bug/1336769

[Steve Martinelli (stevemar)]

Bumping this to medium since the workaround i suggested doesn't work

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/276873
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=448778a51126a79676e9f9ffcc9eaf4c06288a73
Submitter: Jenkins
Branch: master

commit 448778a51126a79676e9f9ffcc9eaf4c06288a73
Author: Rudolf Vriend <email address hidden>
Date: Fri Feb 5 19:58:53 2016 +0100

    Adds user_description_attribute mapping support to the LDAP backend

    The LDAP backend supports mapping between LDAP and keystone user
    attributes via the 'user_<attribute_name>_attribute' settings in the
    LDAP driver configuration.

    The current implementation is incomplete, since there is no support for
    specifying a 'user_description_attribute' setting for user get (read)
    operations.

    This change adds support to the LDAP backend for mapping of user
    description attributes via a 'user_description_attribute' configuration
    also during user retrieval.

    Change-Id: I30b63306beae3379aa8c29d0df3f327369d3f2a6
    Closes-Bug: #1542417

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/keystone 9.0.0.0b3 development milestone.