[openstack-dev] [keystone] LDAP identity driver with groups from local DB
ayoung at redhat.com
Fri Jul 24 18:02:27 UTC 2015
On 07/24/2015 12:00 AM, Julian Edwards wrote:
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev