<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">So, here is the direction we are going:<br>
<br>
Federation allows us to remove the need to have a Backend LDAP
driver at all. Instead, we at Red Hat are planning on build
solutions around using mod_identity_lookup and sssd. The Keystone
server machine will be configured with LDAP PAM and nsswitch
modules that allow the basic native library calls to work for
things like getpwnam etc. The end effect will be that there are
no users "in" the Keystone backend, merely the mappings from the
environment variables REMOTE_USER and REMOTE_USER_GROUPS to
userid/username and groupid. I'm still in the proof of concept
stage with this, but should have a workable solution midway
through the Juno design cycle.<br>
<br>
There are a couple features we need to make this a viable solution
to your problem:<br>
<br>
1. The ability to scope the Federated mapping to the appropriate
domain. This requires a degree of "higher power" interaction so
that domain admins cannot steal eacho others data, especially
userids.<br>
<br>
2. The ability to pass groups directly through to the keystone
server from attributes. THe current implementation requires an
explicit mapping from REMOTE_USER_GROUPS to a group as defined in
the Identity backend.<br>
<br>
Long term, I would expect to have the service users specified in
Keystone in their own domain that is explicitly in Keystone, and
all other users specified via the Federated APIs, and ephemeral to
Keystone itself.<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 05/01/2014 07:48 PM, Adam Young wrote:<br>
</div>
<blockquote cite="mid:5362DD44.1090009@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 05/01/2014 06:17 PM, Lillie
Ross-CDSR11 wrote:<br>
</div>
<blockquote
cite="mid:6AFA470F-9A9B-4DEE-B446-B11BF192887F@motorolasolutions.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
I’ve been playing with using LDAP authentication (identity) and
SQL authorization (assignment) within Keystone in the current
devstack release running in a single VM.
<div><br>
</div>
<div>The problem with this setup, as I understand it, is the
need to have LDAP entries for each service user (i.e. nova,
glance, etc.). In our environment, this isn’t possible as our
corporate LDAP directory is solely for employee records.
While I could work around this issue by running each service
under a known LDAP employee record - this seems rather a
kludge to me.</div>
<div><br>
</div>
<div>My question is, and admittedly I’m not well versed in
directory federation, is this an issue that could be resolved
once directory federation is stable in the next Openstack
release? Where, for instance, all of the openstack service
accounts could remain in a separate directory service
controlled solely by the cloud owner/admin, while user’s could
then be authenticated via the corporate employee LDAP
database?</div>
<div><br>
</div>
<div>We’d love to use LDAP to authenticate cloud user’s, but
with the need to also authenticate openstack services against
the same LDAP backend makes the use of LDAP unviable in our
environment.</div>
</blockquote>
We have no solution for that under Icehouse. This topic is one of
the high priorities for the Keytone team at the Icehouse summit.<br>
<br>
<br>
<blockquote
cite="mid:6AFA470F-9A9B-4DEE-B446-B11BF192887F@motorolasolutions.com"
type="cite">
<div><br>
</div>
<div>This has probably been discussed previously, but any
insight would be helpful. </div>
<div><br>
</div>
<div>Thanks and regards,</div>
<div>Ross</div>
<div><span style="orphans: 2; text-align: -webkit-auto; widows:
2;">--</span></div>
<div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; word-spacing:
0px; -webkit-text-stroke-width: 0px; orphans: 2; widows: 2;
word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;">
<div>Ross Lillie</div>
<div>Distinguished Member of Technical Staff</div>
<div>Motorola Solutions, Inc.</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="http://motorolasolutions.com">motorolasolutions.com</a></div>
</div>
<span style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px; float:
none; display: inline !important;">O: +1.847.576.0012</span>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"> M:
+1.847.980.2241</div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"> E: <a
moz-do-not-send="true"
href="mailto:ross.lillie@motorolasolutions.com">ross.lillie@motorolasolutions.com</a></div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;"> <br>
</div>
<div class="page" title="Page 1" style="color: rgb(0, 0, 0);
font-family: Helvetica; font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: auto; text-align:
start; text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px;"> <br
class="Apple-interchange-newline">
<span><img apple-inline="yes"
id="75293143-DF46-4865-B00D-69EF41222A69"
apple-width="yes" apple-height="yes"
src="cid:part3.03040507.01090101@redhat.com" height="33"
width="277"></span> </div>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mailing list: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a>
Post to : <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>
Unsubscribe : <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a>
Post to : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a>
</pre>
</blockquote>
<br>
</body>
</html>