<tt><font size=2>On 03/07/2014 12:03 PM, Anna A Sortland wrote:<br>
> The current keystone LDAP community driver returns all users that
exist<br>
> in LDAP via the API call v3/users, instead of returning just users
that<br>
> have role grants (similar processing is true for groups). This could<br>
> potentially be a very large number of users. We have seen large<br>
> companies with LDAP servers containing hundreds and thousands of users.<br>
> We are aware of the filters available in keystone.conf<br>
> ([ldap].user_filter and [ldap].query_scope) to cut down on the number
of<br>
> results, but they do not provide sufficient filtering (for example,
it<br>
> is not possible to set user_filter to members of certain known groups<br>
> for OpenLDAP without creating a memberOf overlay on the LDAP server).<br>
> What was the reason the LDAP driver was written this way, instead
of<br>
> returning just the users that have OpenStack-known roles?<br>
<br>
What attributes would you filter on?  It seems to me that LDAP would<br>
need to have knowledge of the roles to be able to filter based on the<br>
roles.  This is not necessarily the case, as identity and assignment
can<br>
be split in Keystone such that identity is in LDAP and role assignment<br>
is in SQL.  I believe it was designed this way to deal with deployments<br>
where LDAP already exists and there is no need (or possibility) of<br>
adding role info into LDAP.</font></tt>
<br>
<br><tt><font size=2><b>That's our main use case. The users and groups
are in LDAP and role assignments are in SQL.</b></font></tt>
<br><tt><font size=2><b>You would filter on role grants and this information
is in SQL backend. So new API would need to query both identity and assignment
drivers.</b></font></tt>
<br><tt><font size=2><br>
Without filtering based on a role attribute in LDAP, I don't think that<br>
there is a good solution if you have OpenStack and non-OpenStack users<br>
mixed in the same container in LDAP.<br>
<br>
If you want to first find all of the users that have a role assigned to<br>
them in the assignments backend, then pull their information from LDAP,<br>
I think that you will end up with one LDAP search operation per user.<br>
This also isn't a very scalable solution.<br>
<br>
> Was the<br>
> creation of a separate API for this function considered?<br>
> <br>
> Are other exploiters of OpenStack (or users of Horizon) experiencing<br>
> this issue? If so, what was their approach to overcome this issue?
We<br>
> have been prototyping a keystone extension that provides an API that<br>
> provides this filtering capability, but it seems like a function that<br>
> should be generally available in keystone.<br>
<br>
I'm curious to know how your prototype is looking to handle this.</font></tt>
<br>
<br><tt><font size=2><b>The prototype basically first calls assignment
API </b></font></tt><font size=2 face="Consolas"><b>list_role_assignments()</b></font><tt><font size=2><b>
to get a list of users and groups with role grants. It then iterates the
retrieved list and calls identity API </b></font></tt><font size=2 face="Consolas"><b>list_users_in_group</b></font><tt><font size=2><b>()
to get the list of users in these groups with grants and </b></font></tt><font size=2 face="Consolas"><b>get_user</b></font><tt><font size=2><b>()
to get users that have role grants but do not belong to the groups with
role grants (a call for each user). Both calls ignore groups and users
that are not found in the LDAP registry but exist in SQL (this could be
the result of a user or group being removed from LDAP, but the corresponding
role grant was not revoked). Then the code removes duplicates if any and
returns the combined list.</b></font></tt>
<br>
<br><tt><font size=2><b>The new extension API is /v3/my_new_extension/users.
Maybe the better naming would be v3/roles/users (list users with any role)
- compare to existing v3/roles/​{role_id}​/users  (list users
with a specified role). </b></font></tt>
<br>
<br><tt><font size=2><b>Another alternative that we've tried is just a
new identity driver that inherits from keystone.identity.backends.ldap.LDAPIdentity
and overrides just the list_users() function. That's probably not the best
approach from OpenStack standards point of view but I would like to get
community's feedback on whether this is acceptable. </b></font></tt>
<br><tt><font size=2><br>
<br>
Thanks,<br>
-NGK<br>
<br>
> <br>
> <br>
> <br>
> Anna Sortland<br>
> Cloud Systems Software Development<br>
> IBM Rochester, MN<br>
> annasort@us.ibm.com</font></tt>
<br>
<br><font size=2 face="sans-serif"><br>
<br>
Anna Sortland</font>
<br><font size=2 face="sans-serif">Cloud Systems Software Development</font>
<br><font size=2 face="sans-serif">IBM Rochester, MN<br>
annasort@us.ibm.com<br>
<br>
<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Nathan Kinder <nkinder@redhat.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">Anna A Sortland/Rochester/IBM@IBMUS,
openstack-security@lists.openstack.org, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">03/07/2014 03:43 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [Openstack-security]
All LDAP users returned using keystone v3/users API</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 03/07/2014 12:03 PM, Anna A Sortland wrote:<br>
> The current keystone LDAP community driver returns all users that
exist<br>
> in LDAP via the API call v3/users, instead of returning just users
that<br>
> have role grants (similar processing is true for groups). This could<br>
> potentially be a very large number of users. We have seen large<br>
> companies with LDAP servers containing hundreds and thousands of users.<br>
> We are aware of the filters available in keystone.conf<br>
> ([ldap].user_filter and [ldap].query_scope) to cut down on the number
of<br>
> results, but they do not provide sufficient filtering (for example,
it<br>
> is not possible to set user_filter to members of certain known groups<br>
> for OpenLDAP without creating a memberOf overlay on the LDAP server).<br>
> What was the reason the LDAP driver was written this way, instead
of<br>
> returning just the users that have OpenStack-known roles?<br>
<br>
What attributes would you filter on?  It seems to me that LDAP would<br>
need to have knowledge of the roles to be able to filter based on the<br>
roles.  This is not necessarily the case, as identity and assignment
can<br>
be split in Keystone such that identity is in LDAP and role assignment<br>
is in SQL.  I believe it was designed this way to deal with deployments<br>
where LDAP already exists and there is no need (or possibility) of<br>
adding role info into LDAP.<br>
<br>
Without filtering based on a role attribute in LDAP, I don't think that<br>
there is a good solution if you have OpenStack and non-OpenStack users<br>
mixed in the same container in LDAP.<br>
<br>
If you want to first find all of the users that have a role assigned to<br>
them in the assignments backend, then pull their information from LDAP,<br>
I think that you will end up with one LDAP search operation per user.<br>
This also isn't a very scalable solution.<br>
<br>
> Was the<br>
> creation of a separate API for this function considered?<br>
> <br>
> Are other exploiters of OpenStack (or users of Horizon) experiencing<br>
> this issue? If so, what was their approach to overcome this issue?
We<br>
> have been prototyping a keystone extension that provides an API that<br>
> provides this filtering capability, but it seems like a function that<br>
> should be generally available in keystone.<br>
<br>
I'm curious to know how your prototype is looking to handle this.<br>
<br>
Thanks,<br>
-NGK<br>
<br>
> <br>
> <br>
> <br>
> Anna Sortland<br>
> Cloud Systems Software Development<br>
> IBM Rochester, MN<br>
> annasort@us.ibm.com<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> Openstack-security mailing list<br>
> Openstack-security@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</font></tt></a><tt><font size=2><br>
> <br>
<br>
</font></tt>
<br>