Public bug reported: A common request we see from corporate environments when providing Active Directory/LDAP integration into keystone is the ability for role assignments to apply for users who are members of a sub-group of the role-assigned group.
For instance, if you have the following groups cn=Project1_Users,dc=com member: user1 member: user2 memberGroup: cn=Project1_Admins,dc=com cn=Project1_Admins,dc=com member: adminuser And you defined Project1 in openstack and then defined group Project1_Users to be assigned "Member" role in Project1, only user1 and user2 would be granted that role, even though adminuser is technically a member of that group from an Active Directory perspective. You would have to also assign Project1_Admins to the "Member" role for Project1 for adminuser to be granted Member rights. The keystone code does not handle subgroup membership for group-role- assignment, so any subgroups of a group that is granted a role, will also have to be individually granted the role under the same project(s). In ActiveDirectory, there is a memberOf OID subquery (memberOf:1.2.840.113556.1.4.1941:=<group dn>) that allows for harnessing the directory's ability to chase sub-group referrals, and it returns a list of user records, however this is not the method that keystone wishes to ingest group members, instead querying a group for it's $group_member_attribute value(s). It would be very useful to either be able to identify a way to query group membership based on this OID query or to define a "group_subgroup_attribute" that keystone would perform cursive lookups through for further members of the role-assigned group. ** Affects: keystone Importance: Undecided Status: New ** Tags: canonical-bootstack -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1815810 Title: [RFE] Allow keystone to query sub-group membership for group role- assignment Status in OpenStack Identity (keystone): New Bug description: A common request we see from corporate environments when providing Active Directory/LDAP integration into keystone is the ability for role assignments to apply for users who are members of a sub-group of the role-assigned group. For instance, if you have the following groups cn=Project1_Users,dc=com member: user1 member: user2 memberGroup: cn=Project1_Admins,dc=com cn=Project1_Admins,dc=com member: adminuser And you defined Project1 in openstack and then defined group Project1_Users to be assigned "Member" role in Project1, only user1 and user2 would be granted that role, even though adminuser is technically a member of that group from an Active Directory perspective. You would have to also assign Project1_Admins to the "Member" role for Project1 for adminuser to be granted Member rights. The keystone code does not handle subgroup membership for group-role- assignment, so any subgroups of a group that is granted a role, will also have to be individually granted the role under the same project(s). In ActiveDirectory, there is a memberOf OID subquery (memberOf:1.2.840.113556.1.4.1941:=<group dn>) that allows for harnessing the directory's ability to chase sub-group referrals, and it returns a list of user records, however this is not the method that keystone wishes to ingest group members, instead querying a group for it's $group_member_attribute value(s). It would be very useful to either be able to identify a way to query group membership based on this OID query or to define a "group_subgroup_attribute" that keystone would perform cursive lookups through for further members of the role-assigned group. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1815810/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp