Open Stack

On 24 July 2015 at 15:26, Boris Bobrov <bbobrov at mirantis.com> wrote:
> On Friday 24 July 2015 09:29:32 Dave Walker wrote:
>> On 24 July 2015 at 05:00, Julian Edwards <bigjools at 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