<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
<br>
<br>
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. <i><br>
<br>
<br>
</i>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<i>.<br>
<br>
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.<br>
</i><br>
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.<br>
<br>
</body>
</html>