Open Stack

On 03/07/2014 12:03 PM, Anna A Sortland wrote:
> 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).
> What was the reason the LDAP driver was written this way, instead of
> returning just the users that have OpenStack-known roles?

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.

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.

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.

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

I'm curious to know how your prototype is looking to handle this.

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. 


Thanks,
-NGK

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



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






From:   Nathan Kinder <nkinder at redhat.com>
To:     Anna A Sortland/Rochester/IBM at IBMUS, 
openstack-security at lists.openstack.org, 
Date:   03/07/2014 03:43 PM
Subject:        Re: [Openstack-security] All LDAP users returned using 
keystone v3/users API



On 03/07/2014 12:03 PM, Anna A Sortland wrote:
> 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).
> What was the reason the LDAP driver was written this way, instead of
> returning just the users that have OpenStack-known roles?

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.

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.

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

I'm curious to know how your prototype is looking to handle this.

Thanks,
-NGK

> 
> 
> 
> Anna Sortland
> Cloud Systems Software Development
> IBM Rochester, MN
> annasort at us.ibm.com
> 
> 
> 
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140310/4f5a9d73/attachment.html>