On 24 July 2015 at 15:26, Boris Bobrov <bbob...@mirantis.com> wrote: > On Friday 24 July 2015 09:29:32 Dave Walker wrote: >> On 24 July 2015 at 05:00, Julian Edwards <bigjo...@gmail.com> wrote: >> Tl;DR is that the *User* management can come from LDAP via the >> Identity driver, but the Project/Tenants and Roles on these come from >> the *Assignment* driver via SQL - almost as an overlay. >> >> This would seem to solve the issue you outline? > > As far as I understand the issue is that corps want to have users in read-only > LDAP and have an ability to create groups outside of LDAP, in SQL. > > Am I right?
I think as you described can already be done. There are SQL and LDAP backends for both Assignment and Identity and a deployment can choose their own mix, including RO for LDAP. However, if you have an enterprise resource / entitlement management system which can map to OpenStack Assignments, but not exposed via SAML or LDAP - you either need to mirror in SQL or SOL. User authentication is pretty solid via the external Identity management as you can simply use anything that sets REMOTE_USER upstream in the web server (Kerberos or X.509 makes sense). The issue I wanted to solve was 'backend' AuthN and AuthZ integration to external systems. The current Federation mechanism relies on getting Assignment (Roles and Groups) from keystone edge service via SAML assertions. I needed to keep Keystone stateless, but use deployment specific plugin to grab User, Project and Role data from a third-party entitlement system at runtime (via a backend plugin). The direction of Keystone (based on the thread I linked to and summit conversations) is to embrace edge Federation more and reduce the backend integration. Which makes sense really.. but when hit with legacy enterprise resource, entitlement and access systems that don't support SAML, the need to absorb tech' debt is a balance. Thankfully, Keystone still makes it quite easy to maintain custom backend drivers. -- Kind Regards, Dave Walker __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
