Open Stack

On 07/24/2015 12:00 AM, Julian Edwards wrote:
> Hello,
>
> I am relatively new to Openstack and Keystone so please forgive me any
> crazy misunderstandings here.
>
> One of the problems with the existing LDAP Identity driver that I see
> is that for group management it needs write access to the LDAP server,
> or requires an LDAP admin to set up groups separately.
>
> Neither of these are palatable to some larger users with corporate
> LDAP directories, so I'm interested in discussing a solution that
> would get acceptance from core devs.
>
> My initial thoughts are to create a new driver that would store groups
> and their user memberships in the local keystone database, while
> continuing to rely on LDAP for user authentication. The advantages of
> this would be that the standard UI tools could continue to work for
> group manipulation.  This is somewhat parallel with ephemeral
> federated user group mappings, but that's all done in the json blob
> which is a bit horrible. (I'd like to see that working with a decent
> UI some time, perhaps it is solved in the same way)

This has come up numerous times, as I am sure you are now aware by 
reading the rest of the thread.

A couple points;  I've been aware of the hybrid driver for several 
years.  I feel it is a security mistake to copy the users from the 
system of record (LDAP) into a cache (Keystone) and then tro only trust 
the values in the cache;  if I delete or disable a user in LDAP, that 
should be the state used, not the cached value.

Groups are tricky things.  While I've often toyed with what you suggest 
here, I always come back to the `group` being an identity attribute that 
exists outside of Keystone, and everything that we do inside of Keystone 
can be done with existing mechanisms in Keystone itself, especially now 
that we have Hierarchical Multitenantcy.

The most common reason for a group is to be able to share access to 
multiple tenants.  This is broken up into a handful of use cases:


1.  All in one organization, multiple projects
2.  Users from a remote organization get mapped in to a local set of 
projects (but not all...)
3.  A virtual organization


  I'd like to see the problems you are dealing with to evaluate if 
splitting groups from users makes sense.




>
> However, one of the other reasons I'm sending this is to gather more
> ideas to solve this. I'd like to hear from anyone in a similar
> position, and anyone with input on how to help.
>
> Cheers,
> Julian.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev