We ran into a similar issues, wanting to authenticate our corporate users against the company AD, but keeping our services accounts separate.
We ended up writing a little piece of Keystone middleware that sits on the Keystone request pipeline. It will attempt to authenticate the user against our corporate authentication API. If that succeeds, it will set the REMOTE_USER variable in the request environment and Keystone will obey it. If it is not set, Keystone will simply authenticate against the built-in database. We’ve been using this method for more than a year and it works well, but I don’t know if this is still the best solution today. It’s a bit specific to our environment, but I can provide you with some example code if that would help. Regards, Jasper Capel On 02 May 2014, at 00:17, Lillie Ross-CDSR11 <ross.lil...@motorolasolutions.com> 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. > > 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 > O: +1.847.576.0012 > M: +1.847.980.2241 > E: ross.lil...@motorolasolutions.com > > > <MSI-Email-Identity-sm.png> > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > Post to : openstack@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@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
