<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 4:20 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Thu, Jan 29, 2015 at 12:31:17PM -0500, Zane Bitter wrote:<br>
> On 29/01/15 12:03, Steven Hardy wrote:<br>
> >On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote:<br>
> >>>IIUC keystone now allows you to add users to a domain that is otherwise<br>
> >>>backed by a read-only backend (i.e. LDAP). If this means that it's now<br>
> >>>possible to configure a cloud so that one need not be an admin to create<br>
> >>>users then I think it would be a really useful thing to expose in Heat. Does<br>
> >>>anyone know if that's the case?<br>
> ><br>
> >I've not heard of that feature, but it's definitely now possible to<br>
> >configure per-domain backends, so for example you could have the "heat"<br>
> >domain backed by SQL and other domains containing real human users backed<br>
> >by a read-only directory.<br>
><br>
> <a href="http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/" target="_blank">http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/</a><br>
<br>
</span>Perhaps we need to seek clarification from Adam/Henry, but my understanding<br>
of that feature is not that it enables you to add users to domains backed<br>
by a read-only directory, but rather that multiple backends are possible,<br>
such that one domain can be backed by a read-only backend, and another<br>
(different) domain can be backed by a different read/write one.<br>
<br>
E.g in the example above, you might have the "freeipa" domain backed by<br>
read-only LDAP which contains your directory of human users, and you might<br>
also have a different domain e.g "services" or "heat" backed by a<br>
read/write backend e.g Sql.<br>
<br>
Steve<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br><div>You might want to think about what can be done using federation. 
Federation allows keystone to talk to external identity providers, where
 these identity providers have the users. What if heat was an identity 
provider? Then heat would have a record of the users and they could be 
used with keystone to get a token.<br></div><div><br></div><div>On a 
similar note, while keystone isn't going to let you create users in a 
read-only LDAP backend, heat could talk directly to the LDAP server to 
create users.<br><br></div>- Brant<br></div></div><br></div></div>