Open Stack

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120201/93c11444/attachment.html>