yahoo-eng-team team mailing list archive

[Michael Steffens <michael_steffens@xxxxxxxxx>]

Public bug reported:

When using a read-only LDAP backend with

* project ID not being represented by CN as part of project DN, but some other attribute (Example: entryUUID provided by ApacheDS)
* this attribute configured as project_id_attribute in keystone.conf

all authentications fail caused failure to retrieve associated projects.
The LDAP assignment backend still tries to extract the ID from project
DN.

Note that project_id_attribute is honored as such (see
https://bugs.launchpad.net/keystone/+bug/1361306).  You can run
"keystone tenant-list" and retrieve the correct result. So this problem
is not a duplicate of the bug mentioned above. Instead the issue
affecting authentication appears to be in

keystone/assignment/backends/ldap.py

in ProjectApi.get_user_projects(), which is

1. Collecting all associated project DNs from user association
2. Incorrectly mapping them to IDs, ignoring project_id_attribute
3. Finally performing subtree searches for these incorrect IDs

Instead, as the LDAP primary keys of the project entries are already
known in first place, it should look them up directly without using the
ID detour.

** Affects: keystone
     Importance: Undecided
         Status: New


** Tags: attribute id keystone ldap

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1409635

Title:
  keystone fails to authenticate users when LDAP project_id_attribute is
  not CN

Status in OpenStack Identity (Keystone):
  New

Bug description:
  When using a read-only LDAP backend with

  * project ID not being represented by CN as part of project DN, but some other attribute (Example: entryUUID provided by ApacheDS)
  * this attribute configured as project_id_attribute in keystone.conf

  all authentications fail caused failure to retrieve associated
  projects. The LDAP assignment backend still tries to extract the ID
  from project DN.

  Note that project_id_attribute is honored as such (see
  https://bugs.launchpad.net/keystone/+bug/1361306).  You can run
  "keystone tenant-list" and retrieve the correct result. So this
  problem is not a duplicate of the bug mentioned above. Instead the
  issue affecting authentication appears to be in

  keystone/assignment/backends/ldap.py

  in ProjectApi.get_user_projects(), which is

  1. Collecting all associated project DNs from user association
  2. Incorrectly mapping them to IDs, ignoring project_id_attribute
  3. Finally performing subtree searches for these incorrect IDs

  Instead, as the LDAP primary keys of the project entries are already
  known in first place, it should look them up directly without using
  the ID detour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1409635/+subscriptions