<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 02/02/2012 02:38 AM, Vishvananda Ishaya wrote:
<blockquote
cite="mid:5F646964-0D5F-41A7-B9FF-3672071A5687@gmail.com"
type="cite">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.</blockquote>
<br>
Based on discussions with numerous people, It seems that the
subtree approach (as done by nova deprecated) is the norm.<br>
<br>
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 <br>
<br>
<a class="moz-txt-link-freetext" href="http://www.openldap.org/faq/data/cache/1133.html">http://www.openldap.org/faq/data/cache/1133.html</a><br>
<a class="moz-txt-link-freetext" href="http://www.openldap.org/faq/data/cache/1134.html">http://www.openldap.org/faq/data/cache/1134.html</a><br>
<br>
Whereas in Active directory, it involves using
LDAP_MATCHING_RULE_IN_CHAIN rule OID. <br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
So, to summarize: Roles will be entites under tenants, with a
member field that indicates the users that have that role. <br>
<br>
<blockquote
cite="mid:5F646964-0D5F-41A7-B9FF-3672071A5687@gmail.com"
type="cite">
<div><br>
</div>
<div>Vish</div>
<div><br>
<div>
<div>On Feb 1, 2012, at 7:56 PM, Adam Young wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div 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>
</div>
_______________________________________________<br>
Mailing list: <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
Post to : <a moz-do-not-send="true"
href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a moz-do-not-send="true"
href="https://launchpad.net/%7Eopenstack">https://launchpad.net/~openstack</a><br>
More help : <a moz-do-not-send="true"
href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>