Open Stack

[A] The current keystone LDAP community driver returns all users that 
exist in LDAP via the API call v3/users, instead of returning just users 
that have role grants (similar processing is true for groups). This could 
potentially be a very large number of users. We have seen large companies 
with LDAP servers containing hundreds and thousands of users. We are aware 
of the filters available in keystone.conf ([ldap].user_filter and 
[ldap].query_scope) to cut down on the number of results, but they do not 
provide sufficient filtering (for example, it is not possible to set 
user_filter to members of certain known groups for OpenLDAP without 
creating a memberOf overlay on the LDAP server). 

[Nathan Kinder] What attributes would you filter on?  It seems to me that 
LDAP would need to have knowledge of the roles to be able to filter based 
on the roles.  This is not necessarily the case, as identity and 
assignment can be split in Keystone such that identity is in LDAP and role 
assignment is in SQL.  I believe it was designed this way to deal with 
deployments
where LDAP already exists and there is no need (or possibility) of adding 
role info into LDAP. 

[A] That's our main use case. The users and groups are in LDAP and role 
assignments are in SQL. 
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. 

[Nathan Kinder] Without filtering based on a role attribute in LDAP, I 
don't think that there is a good solution if you have OpenStack and 
non-OpenStack users mixed in the same container in LDAP.
If you want to first find all of the users that have a role assigned to 
them in the assignments backend, then pull their information from LDAP, I 
think that you will end up with one LDAP search operation per user. This 
also isn't a very scalable solution.

[A] What was the reason the LDAP driver was written this way, instead of 
returning just the users that have OpenStack-known roles? Was the creation 
of a separate API for this function considered? 
Are other exploiters of OpenStack (or users of Horizon) experiencing this 
issue? If so, what was their approach to overcome this issue? We have been 
prototyping a keystone extension that provides an API that provides this 
filtering capability, but it seems like a function that should be 
generally available in keystone.

[Nathan Kinder] I'm curious to know how your prototype is looking to 
handle this. 

[A] The prototype basically first calls assignment API 
list_role_assignments() to get a list of users and groups with role 
grants. It then iterates the retrieved list and calls identity API 
list_users_in_group() to get the list of users in these groups with grants 
and get_user() 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. 

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). 


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. 


I've posted this question to openstack-security last week but could not 
get any feedback after Nathan's first reply. Reposting to openstack-dev..



Anna Sortland
Cloud Systems Software Development
IBM Rochester, MN
annasort at us.ibm.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140313/9c3ee15f/attachment.html>