Open Stack

So, here is the direction we are going:

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.

There are a couple features we need to make this a viable solution to 
your problem:

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.

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.

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.






On 05/01/2014 07:48 PM, Adam Young wrote:
> On 05/01/2014 06:17 PM, Lillie Ross-CDSR11 wrote:
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> 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.
> We have no solution for that under Icehouse.  This topic is one of the 
> high priorities for the Keytone team at the Icehouse summit.
>
>
>>
>> This has probably been discussed previously, but any insight would be 
>> helpful.
>>
>> Thanks and regards,
>> Ross
>> --
>> Ross Lillie
>> Distinguished Member of Technical Staff
>> Motorola Solutions, Inc.
>>
>> motorolasolutions.com <http://motorolasolutions.com>
>> O: +1.847.576.0012
>> M: +1.847.980.2241
>> E: ross.lillie at motorolasolutions.com 
>> <mailto:ross.lillie at motorolasolutions.com>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list:http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     :openstack at lists.openstack.org
>> Unsubscribe :http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140502/1e633f1c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10441 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140502/1e633f1c/attachment.png>