<font size=2 face="sans-serif">Hi Nathan, </font>
<br><font size=2 face="sans-serif">I agree that we should be using filters
on LDAP search whenever possible. I still believe it is a valid use case
for a new 'roles' API to retrieve users with role grants and I am not sure
it is possible to do without querying LDAP for one user at a time. </font>
<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">"OpenStack Development
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">03/13/2014 09:50 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [openstack-dev]
[keystone] All LDAP users returned using keystone v3/users API</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>On 03/13/2014 08:36 AM, Anna A Sortland wrote:<br>
> [A] The current keystone LDAP community driver returns all users that<br>
> exist in LDAP via the API call v3/users, instead of returning just
users<br>
> that have role grants (similar processing is true for groups). This<br>
> could 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>
> <br>
> [Nathan Kinder] What attributes would you filter on?  It seems
to me<br>
> that LDAP would need to have knowledge of the roles to be able to
filter<br>
> based on the roles.  This is not necessarily the case, as identity
and<br>
> assignment can be split in Keystone such that identity is in LDAP
and<br>
> role assignment is in SQL.  I believe it was designed this way
to deal<br>
> with deployments<br>
> where LDAP already exists and there is no need (or possibility) of<br>
> adding role info into LDAP.<br>
> <br>
> [A] That's our main use case. The users and groups are in LDAP and
role<br>
> assignments are in SQL.<br>
> You would filter on role grants and this information is in SQL backend.<br>
> So new API would need to query both identity and assignment drivers.<br>
> <br>
> [Nathan Kinder] Without filtering based on a role attribute in LDAP,
I<br>
> don't think that there is a good solution if you have OpenStack and<br>
> non-OpenStack users mixed in the same container in LDAP.<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>
> [A] What was the reason the LDAP driver was written this way, instead
of<br>
> returning just the users that have OpenStack-known roles? Was the<br>
> creation of a separate API for this function considered?<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>
> [Nathan Kinder] I'm curious to know how your prototype is looking
to<br>
> handle this.<br>
> <br>
> [A] The prototype basically first calls assignment API<br>
> list_role_assignments() to get a list of users and groups with role<br>
> grants. It then iterates the retrieved list and calls identity API<br>
> list_users_in_group() to get the list of users in these groups with<br>
> grants and get_user() to get users that have role grants but do not<br>
> belong to the groups with role grants (a call for each user). Both
calls<br>
> ignore groups and users that are not found in the LDAP registry but<br>
> exist in SQL (this could be the result of a user or group being removed<br>
> from LDAP, but the corresponding role grant was not revoked). Then
the<br>
> code removes duplicates if any and returns the combined list.<br>
<br>
My main concern about this is that you have a single LDAP search<br>
operation per user.  This will get you the correct results, but it
isn't<br>
very efficient for the LDAP server if you have a large number of users.<br>
 Performing a single LDAP search operation will perform better if there<br>
is some attribute you can use to filter on, as the connection handling<br>
and operation parsing overhead will be much less.  If you are unable
to<br>
add an attribute in LDAP that identifies users that Keystone should list<br>
(such as memberOf), you may not have much choice other than your proposal.<br>
<br>
> <br>
> The new extension API is /v3/my_new_extension/users. Maybe the better<br>
> naming would be v3/roles/users (list users with any role) - compare
to<br>
> existing v3/roles/​{role_id}​/users  (list users with a specified
role).<br>
> <br>
> Another alternative that we've tried is just a new identity driver
that<br>
> inherits from keystone.identity.backends.ldap.LDAPIdentity and overrides<br>
> just the list_users() function. That's probably not the best approach<br>
> from OpenStack standards point of view but I would like to get<br>
> community's feedback on whether this is acceptable.<br>
> <br>
> <br>
> I've posted this question to openstack-security last week but could
not<br>
> get any feedback after Nathan's first reply. Reposting to openstack-dev..<br>
<br>
Sorry for the delay in replying.  This list is a better place to discuss<br>
this anyway, as you will get more visibility.<br>
<br>
Thanks,<br>
-NGK<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>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>