<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 24, 2015 at 1:10 AM, Henry Nash <span dir="ltr"><<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Matt,<div><br></div><div>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?</div><div><br></div><div>Henry<br></div></div></blockquote><div><br></div><div><br></div><div>Henry,</div><div><br></div><div>First to clarify I don't want to call it my driver since the guys at SuSe wrote it. It has 2 pieces, identity and assignment, we only use the identity driver. AFAIK Assignment via LDAP is being deprecated anyway. Since we have no ability to move users into LDAP groups and what not at our company, we only use the driver I mentioned to do an LDAP bind and everything else happens in mysql.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div><div class="h5"><div>On 24 Jul 2015, at 05:51, Matt Fischer <<a href="mailto:matt@mattfischer.com" target="_blank">matt@mattfischer.com</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr">Julian,<div><br></div><div>You want this hybrid backend driver. Bind against LDAP for auth, store everything else in mysql:</div><div><br></div><div><a href="https://github.com/SUSE-Cloud/keystone-hybrid-backend" target="_blank">https://github.com/SUSE-Cloud/keystone-hybrid-backend</a><br></div><div><br></div><div>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.</div><div><br></div><div>I know some of the Keystone team has pretty strong opinions about this but it works for us.</div><div><br></div><div>And nice to run into you again...</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 23, 2015 at 10:00 PM, Julian Edwards <span dir="ltr"><<a href="mailto:bigjools@gmail.com" target="_blank">bigjools@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Hello,<br>
<br>
I am relatively new to Openstack and Keystone so please forgive me any<br>
crazy misunderstandings here.<br>
<br>
One of the problems with the existing LDAP Identity driver that I see<br>
is that for group management it needs write access to the LDAP server,<br>
or requires an LDAP admin to set up groups separately.<br>
<br>
Neither of these are palatable to some larger users with corporate<br>
LDAP directories, so I'm interested in discussing a solution that<br>
would get acceptance from core devs.<br>
<br>
My initial thoughts are to create a new driver that would store groups<br>
and their user memberships in the local keystone database, while<br>
continuing to rely on LDAP for user authentication. The advantages of<br>
this would be that the standard UI tools could continue to work for<br>
group manipulation.  This is somewhat parallel with ephemeral<br>
federated user group mappings, but that's all done in the json blob<br>
which is a bit horrible. (I'd like to see that working with a decent<br>
UI some time, perhaps it is solved in the same way)<br>
<br>
However, one of the other reasons I'm sending this is to gather more<br>
ideas to solve this. I'd like to hear from anyone in a similar<br>
position, and anyone with input on how to help.<br>
<br>
Cheers,<br>
Julian.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br></div></div>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div><span class="">
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br></span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></blockquote></div><br></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>