Inconsistent use of tenant_id, tenantId, default_project_id across identity drivers for the User object/ref

Bug #1219739 reported by kaitian521 on 2013-09-02
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
High
Morgan Fainberg

Bug Description

When LDAP backend is configured, "keystone user-get <user-id>" can *NOT* display 'tanantId'.

I looked up the code, user in LDAP dose not have attribute "tenantId", but it has an attribute named "tenant_id".

This problem blocks us.

Dolph Mathews (dolph) on 2013-09-02
Changed in keystone:
milestone: none → havana-rc1
importance: Undecided → Medium
Dolph Mathews (dolph) wrote :

A fix for this bug should un-skip tests introduced in https://review.openstack.org/#/c/42826/

Changed in keystone:
assignee: nobody → Morgan Fainberg (mdrnstm)
Morgan Fainberg (mdrnstm) wrote :

By default the tenant_id is not stored by the LDAP backend (or in the case of v2.0 tenantId). This appears to be an intentional choice as there is no attribute mapping on the back end. There is also inconsistency in the use of tenant_id, tenantId, and default_project_id across the different drivers and versions of API.

The solution will be as follows:
* Provide a mapping for LDAP attributes to set/store the default_project_id
* SQL, make default_project_id a full column in the identity backend
* Put in translation code to return "tenantId" for v2.0 gets on the user, and "default_project_id" for v3 user gets
* Put in translation code to normalize the backend to the correct values.

LDAP will still, by default, not store the default_project_id, however, the option to configure it to store the data will be available. Unless keystone's configuration defaults are changed, it will not be returned nor stored (in the LDAP identity driver) via use of the RESTful api or the keystoneclient.

Changed in keystone:
importance: Medium → High
summary: - LDAP use 'tenant_id' instead of 'tenantId' in user_ref
+ Inconsistent use of tenant_id, tenantId, default_project_id across
+ identity drivers for the User object/ref

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

Changed in keystone:
status: New → In Progress

Reviewed: https://review.openstack.org/46207
Committed: http://github.com/openstack/keystone/commit/dda19c3977cd12bd6694a3bc932539ca2b08aee9
Submitter: Jenkins
Branch: master

commit dda19c3977cd12bd6694a3bc932539ca2b08aee9
Author: Morgan Fainberg <email address hidden>
Date: Thu Sep 12 00:11:45 2013 -0700

    Cleanup of tenantId, tenant_id, and default_project_id

    This patchset normalizes the use of tenantId, tenant_id, and
    default_project_id across the Identity backend. This includes
    making default_project_id no longer part of the "extra" json blob
    on the user object and migrating all "tenantId" "tenant_id" and
    "default_project_id" into the new column (SQL).

    In the LDAP driver, None is set as the mapping for
    default_project_id. This means that use of default_project_id with
    LDAP Identity will require an explicit mapping to be defined by the
    cloud operator.

    "default_project_id" remains (by default) configured to be in the
    "ignore" attributes for the LDAP driver, so 'tenantId' and
    'default_project_id' will not be saved on the user_object during
    update or create unless Keystone is explicitly configured to do so.

    closes-bug: 1219739
    closes-bug: 1226475
    related-bug: 1201251
    Change-Id: I07f9dfe111646884ac5efd42fc8c2974188b3b94

Changed in keystone:
status: In Progress → Fix Committed
kaitian521 (kaitian521) wrote :

Thanks for Margan

Thierry Carrez (ttx) on 2013-10-02
Changed in keystone:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-rc1 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers