LDAP backend lacks support for user_description_attribute mapping

Bug #1542417 reported by Rudolf Vriend on 2016-02-05
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Rudolf Vriend

Bug Description

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.

Changed in keystone:
assignee: nobody → Rudolf Vriend (rudolf-vriend)

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

Changed in keystone:
status: New → In Progress
description: updated
summary: - ldap backend lacks support for user_description_attribute mapping
+ LDAP backend lacks support for user_description_attribute mapping
Steve Martinelli (stevemar) wrote :

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

Changed in keystone:
importance: Undecided → Wishlist
Rudolf Vriend (rudolf-vriend) wrote :

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) wrote :

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

Changed in keystone:
importance: Wishlist → Medium
Changed in keystone:
milestone: none → mitaka-3

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

Changed in keystone:
status: In Progress → Fix Released

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers