[Openstack] Capture of the Keystone/LDAP Role discussion

Adam Young ayoung at redhat.com
Thu Feb 2 15:31:40 UTC 2012


On 02/02/2012 02:38 AM, Vishvananda Ishaya wrote:
> Nice summary.  As you said ldap structures are going to vary by 
> company.  I am curious if AD has a standard way of dealing with this 
> that we could use. FWIW, the nova deprecated ldap auth code uses 
> subtrees for roles, and yes it is painful, but it might be the way to 
> go if we want something quick and we assume organizations are going to 
> have to write their own version anyway.

Based on discussions with numerous people,  It seems that the subtree 
approach (as done by nova deprecated)  is the norm.

What seems to vary the most amongst LDAP servers is not the schema,  but 
the method used to query for membership in nested groups.   In 
OpenLDAP,  the syntax involves sets

http://www.openldap.org/faq/data/cache/1133.html
http://www.openldap.org/faq/data/cache/1134.html

Whereas in Active directory,  it involves  using 
LDAP_MATCHING_RULE_IN_CHAIN rule OID.

In the 389 (Fedora) Directory Server as well as OpenLDAP it is also 
possible to use   the deference control in conjunction with the  
memberof plugin.


However,  we might not need to query for nested group membership.  For 
example, lets assume a tenant has 3 administrative roles:  user 
management,  network management, VM management. In addition,  users that 
do not have an explicit admin role get read only access to the resources 
of that tenant.  So a user that has the right to manage networks for 
that tenant would have to appear in both the members list of that tenant 
as well as in the networkMgmt role.  The first is provided for read only 
access, and the second for the ability to modify the network.  It is a 
little redundant.  We could perhaps put a constraint on the roles that 
they will only allow users that are listed in the general membership for 
that tenancy.

There was some talk about nesting tenancies for resellers.  This is 
somewhat different from nested group member ship, as entry in the lower 
level tenant should *not* provide access to all resources of the 
containing tenancy.  Permissions go the other way around:  if I am an 
admin of the container,  I can manage elements of the contained.  It 
does mean that the Keystone server needs to be smart enough to check all 
of the levels of nesting from lowest to highest to see if a user has the 
appropriate role for the requested operation.

So,  to summarize:  Roles will be entites under tenants,  with a member 
field that indicates the users that have that role.

>
> Vish
>
> On Feb 1, 2012, at 7:56 PM, Adam Young wrote:
>
>> As part of the effort to get LDAP support into Keystone Light,  we 
>> had a bit of a design discussion on IRC.  The discussion focused on 
>> Roles, and I would like to sum up what was said in that discussion.
>>
>> When we talk about Roles,  we mean the permissions a given user has 
>> in a given tenant.  As such,  it is a three way relationship, and 
>> LDAP does not handle those well.  Group member ship is done using a 
>> multivalued attribute,  such that a Group has a list of users in an 
>> attribute named "members."    This cannot be extended to roles 
>> directly,  as the attribute would have to hold two values:  the 
>> user,  and the role.   One proposal was to do just that: to append 
>> the role name on to the user name,  and them as a single string 
>> inside a single attribute.  A drawback to this approach is that the 
>> LDAP rules have no way of enforcing that the values placed into the 
>> concatenated string are valid values.  Another drawback is that the 
>> parsing of the string is then placed on the system that consumes the 
>> roles.
>>
>>
>> Groups can be containers of other objects.  As such, another 
>> alternative is to put a collection of  roles under the tenant group,  
>> and then to add the user names to each of the roles.    The drawback 
>> to this approach is that the tenant then becomes a subtree, and the 
>> management of subtrees is more involved in  LDAP than the management 
>> of single objects. /
>>
>>
>> /Roles tend to map to permissions on external objects.  For example,  
>> a role might indicate that a given user can create a new network 
>> inside of quantum,  or deploy a new template image into glance.  If 
>> the set of roles is known a-priori,  they could be done as a set of 
>> attributes on the tenant group.  The drawback with this approach is 
>> that  making changes to the LDAP schema after deployment is generally 
>> not allowed in large organizations, so adding a new role would be 
>> impossible/.
>>
>> If the objects being managed were entirely within the Directory 
>> Server, one possible solution would be to use the Directory servers 
>> access controls to manage who could do what.  For example,  in order 
>> for a user to be able to create a new network, they wound need write 
>> access to the networks collection for their tenancy.  The reason we 
>> cannot do that is that many of the objects are maintained in external 
>> databases,  and not in the directory server.  Plus,  the access 
>> controls for LDAP are not guaranteed to be consistent across 
>> different LDAP management systems.
>> /
>> One point that came up repeatedly is that different organizations are 
>> going to have very different LDAP structures,  and the Keystone 
>> architecture would ideally be flexible enough to map to what any 
>> given organization has implemented, albeit with some customization.
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack 
>> <https://launchpad.net/%7Eopenstack>
>> Post to     : openstack at lists.launchpad.net 
>> <mailto:openstack at lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack 
>> <https://launchpad.net/%7Eopenstack>
>> More help   : https://help.launchpad.net/ListHelp
>

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


More information about the Openstack mailing list