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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
