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 <[email protected]> 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 <[email protected]> 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 : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
