<font size=2 face="sans-serif">Hi Mark, </font>
<br>
<br><font size=2 face="sans-serif">The existing v3/users API will still
exist and will show all users. So you will still be able to grant role
to a user who does not have one now.</font>
<br><font size=2 face="sans-serif">I wonder if it makes sense to add a
new API that would show only users that have role grants. </font>
<br>
<br><font size=2 face="sans-serif">So we would have:</font>
<br><font size=2 face="sans-serif">v3/users - list all users   (existing
API)</font>
<br><font size=2 face="sans-serif">v3/roles/users - list users that have
role grants   (new API)</font>
<br><font size=2 face="sans-serif">v3/roles/​{role_id}​/users - list
users with a specified role (existing API)</font>
<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">Mark Washenberger <mark.washenberger@markwash.net></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 01:01 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><font size=3>Hi Anna,</font>
<br><font size=3><br>
</font>
<br><font size=3>On Thu, Mar 13, 2014 at 8:36 AM, Anna A Sortland <</font><a href=mailto:annasort@us.ibm.com target=_blank><font size=3 color=blue><u>annasort@us.ibm.com</u></font></a><font size=3>>
wrote:</font>
<br><font size=3 face="sans-serif">[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). <br>
<br>
[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<br>
where LDAP already exists and there is no need (or possibility) of adding
role info into LDAP. <br>
<br>
[A] That's our main use case. The users and groups are in LDAP and role
assignments are in SQL. <br>
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. </font>
<br>
<br><font size=3>From my perspective, it seems there is a chicken-and-egg
problem with this proposal. If a user doesn't have a role assigned, the
user does not show up in the list. But if the user doesn't show up in the
list, the user doesn't exist. If the user doesn't exist, you cannot add
a role to it.</font>
<br>
<br><font size=3>Perhaps what is needed is just some sort of filter to
listing users that only returns users with a role in the cloud?</font>
<br>
<br><font size=3> </font>
<br><font size=3 face="sans-serif"><br>
[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.<br>
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.<br>
<br>
[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? <br>
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.</font><font size=3> </font><font size=3 face="sans-serif"><br>
<br>
[Nathan Kinder] I'm curious to know how your prototype is looking to handle
this. <br>
<br>
[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. <br>
<br>
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). <br>
<br>
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. </font><font size=3><br>
<br>
</font><font size=3 face="sans-serif"><br>
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..</font><font size=3>
<br>
</font><font size=3 face="sans-serif"><br>
<br>
<br>
Anna Sortland</font><font size=3> </font><font size=3 face="sans-serif"><br>
Cloud Systems Software Development</font><font size=3> </font><font size=3 face="sans-serif"><br>
IBM Rochester, MN</font><font size=3 color=blue face="sans-serif"><u><br>
</u></font><a href=mailto:annasort@us.ibm.com target=_blank><font size=3 color=blue face="sans-serif"><u>annasort@us.ibm.com</u></font></a><font size=3 face="sans-serif"><br>
<br>
</font><font size=3><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list</font><font size=3 color=blue><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org"><font size=3 color=blue><u>OpenStack-dev@lists.openstack.org</u></font></a><font size=3 color=blue><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target=_blank><font size=3 color=blue><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size=3><br>
</font>
<br><tt><font size=2>_______________________________________________<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>