yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #31695
[Bug 1417774] Re: LDAP groups role assignment not reported
[Expired for Keystone because there has been no activity for 60 days.]
** Changed in: keystone
Status: Incomplete => Expired
--
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):
Expired
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
References