Open Stack

I think the issue is groups are very nice for managing sets of users through the web ui but users can only be in groups maintained by the same backend, and ldap backends tend to be readonly. It would be very handy if groups could include users from other domains. Maybe the db could be extended to support a domain column for groups?

Thanks,
Kevin

________________________________
From: Steve Martinelli
Sent: Thursday, July 23, 2015 9:50:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB


The LDAP driver for identity shouldn't require write access to look up groups. It'll only require write access if you want to allow Keystone to create/delete/update new groups.
Not sure what you mean by "requires an LDAP admin to set up groups separately" either. Have any more details you can share?

Thanks,

Steve Martinelli
OpenStack Keystone Core

Julian Edwards <bigjools at gmail.com> wrote on 2015/07/24 12:00:33 AM:

> From: Julian Edwards <bigjools at gmail.com>
> To: openstack-dev at lists.openstack.org
> Date: 2015/07/24 12:01 AM
> Subject: [openstack-dev] [keystone] LDAP identity driver with groups
> from local DB
>
> 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)
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/42269e99/attachment.html>