yahoo-eng-team team mailing list archive

[Mariusz Kruk <kruk@xxxxxxxxxxxxxx>]

Public bug reported:

The bug seems similar in appearance to #1285065, but the cause seems different than the one described there.
What I'm having configured:

group_objectclass=groupOfNames
group_id_attribute=cn
group_name_attribute=ou
group_member_attribute=member
group_desc_attribute=description

What I'm expecting (after adding appropriate entries to the directory, of course):
# keystone user-role-list --tenant-id testProject --user-id myuser
WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).
+----------------------------------+-------+--------------+-------------+
|                id                |  name |   user_id    |  tenant_id  |
+----------------------------------+-------+--------------+-------------+
| 780bd000a6d84f329c3ba361f0dfa4a4 | admin | myuser | testProject |
+----------------------------------+-------+--------------+-------------+

What I'm getting:
# keystone user-role-list --tenant-id testProject --user-id myuser
WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).
[nothing here]

Adding LOG.debug() in various parts of the source code led me to the
conclusion that someone had made some strange assumption about group
object DN and while comparing it in assignment/backends/ldap.py thrown
in some strange "case unification" in form of a upper() call without
caring to think how the other side of the check looks.

The function get_group_project_roles() makes role_list based on
comparison between group_dns  list and groups which are used in role
assignment. I assume that someone made this comparison based on his LDAP
directory structure in which some entries/attributes were named all-
uppercase, but in real life DN's can be any case
(cn=user,ou=users,dc=example and cn=UsEr,ou=Users,dc=example are the
same object).

So the right solution here, I believe will be to make sure that the list in which we will later be looking for upper-cased group DN is itself upper-cased.
In other words in get_group_project_roles() method we should change 
        group_dns = [self.group._id_to_dn(group_id) for group_id in groups]
to
        group_dns = [self.group._id_to_dn(group_id).upper() for group_id in groups]

** Affects: keystone
     Importance: Undecided
         Status: New

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

Title:
  LDAP groups role assignment not reported

Status in OpenStack Identity (Keystone):
  New

Bug description:
  The bug seems similar in appearance to #1285065, but the cause seems different than the one described there.
  What I'm having configured:

  group_objectclass=groupOfNames
  group_id_attribute=cn
  group_name_attribute=ou
  group_member_attribute=member
  group_desc_attribute=description

  What I'm expecting (after adding appropriate entries to the directory, of course):
  # keystone user-role-list --tenant-id testProject --user-id myuser
  WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).
  +----------------------------------+-------+--------------+-------------+
  |                id                |  name |   user_id    |  tenant_id  |
  +----------------------------------+-------+--------------+-------------+
  | 780bd000a6d84f329c3ba361f0dfa4a4 | admin | myuser | testProject |
  +----------------------------------+-------+--------------+-------------+

  What I'm getting:
  # keystone user-role-list --tenant-id testProject --user-id myuser
  WARNING: Bypassing authentication using a token & endpoint (authentication credentials are being ignored).
  [nothing here]

  Adding LOG.debug() in various parts of the source code led me to the
  conclusion that someone had made some strange assumption about group
  object DN and while comparing it in assignment/backends/ldap.py thrown
  in some strange "case unification" in form of a upper() call without
  caring to think how the other side of the check looks.

  The function get_group_project_roles() makes role_list based on
  comparison between group_dns  list and groups which are used in role
  assignment. I assume that someone made this comparison based on his
  LDAP directory structure in which some entries/attributes were named
  all-uppercase, but in real life DN's can be any case
  (cn=user,ou=users,dc=example and cn=UsEr,ou=Users,dc=example are the
  same object).

  So the right solution here, I believe will be to make sure that the list in which we will later be looking for upper-cased group DN is itself upper-cased.
  In other words in get_group_project_roles() method we should change 
          group_dns = [self.group._id_to_dn(group_id) for group_id in groups]
  to
          group_dns = [self.group._id_to_dn(group_id).upper() for group_id in groups]

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