[openstack-dev] [keystone] LDAP identity driver with groups from local DB

Henry Nash henryn at linux.vnet.ibm.com
Fri Jul 24 07:10:53 UTC 2015


Matt,

Your hybrid driver seems to be doing something different than what Julian was asking - namely providing some “automatic role assignments” for users stored in LDAP (unless I am not understanding your patch)?  I guess you could argue that’s a restricted version of being able to create group memberships outside of LDAP (which is Julian what I think you are asking for….), but probably a somewhat different use case?

Henry
> On 24 Jul 2015, at 05:51, Matt Fischer <matt at mattfischer.com> wrote:
> 
> Julian,
> 
> You want this hybrid backend driver. Bind against LDAP for auth, store everything else in mysql:
> 
> https://github.com/SUSE-Cloud/keystone-hybrid-backend <https://github.com/SUSE-Cloud/keystone-hybrid-backend>
> 
> We maintain our own fork with has a few small differences. I do not use the assignment portion of the driver and I'm not sure anyone does so keep that in mind.
> 
> I know some of the Keystone team has pretty strong opinions about this but it works for us.
> 
> And nice to run into you again...
> 
> On Thu, Jul 23, 2015 at 10:00 PM, Julian Edwards <bigjools at gmail.com <mailto:bigjools at gmail.com>> 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)
> 
> 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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> __________________________________________________________________________
> 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/18a1c1b7/attachment.html>


More information about the OpenStack-dev mailing list