Open Stack

In fact, my concern is that we are going to adapt essex release for new big
installation, but it can become very painful to move to new ksl afterwards
for update. I hope it'll not.

Kind regards, Yuriy.



On Thu, Feb 2, 2012 at 12:12, Yuriy Taraday <yorik.sar at gmail.com> wrote:

> We have a project running that will definitely verify if current LDAP
> backend can work with legacy AD. Are you going to change a lot of things in
> backends?
> I believe that current model (tree for global roles definitions and all
> tenant roles as groups in tenant's subtree) is very flexible and represents
> common structure used in existing LDAP services.
>
> Kind regards, Yuriy.
>
>
>
> On Thu, Feb 2, 2012 at 07:56, Adam Young <ayoung at redhat.com> 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
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120202/44786f9f/attachment.html>