Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Julian Edwards]

On 25 July 2015 at 04:02, Adam Young  wrote:
> This has come up numerous times, as I am sure you are now aware by reading
> the rest of the thread.

Yes indeed :)  I was thinking as I wrote it that I can't be the first
person with this question.

However I think Daviey has shown me that I was misunderstanding how
assignment worked, and I suspect that I can do what I need to do
already
(Thanks Dave!).

Having said that, I still think there's value in doing more with
groups, more below.

> A couple points;  I've been aware of the hybrid driver for several years.  I
> feel it is a security mistake to copy the users from the system of record
> (LDAP) into a cache (Keystone) and then tro only trust the values in the
> cache;  if I delete or disable a user in LDAP, that should be the state
> used, not the cached value.
>
> Groups are tricky things.  While I've often toyed with what you suggest
> here, I always come back to the `group` being an identity attribute that
> exists outside of Keystone, and everything that we do inside of Keystone can
> be done with existing mechanisms in Keystone itself, especially now that we
> have Hierarchical Multitenantcy.

I've honestly never thought of "group" being an identity attribute;
for me it relates to authorization management — being part of a group
grants access to something.  Anyway, that's slightly tangential to
this discussion.

> The most common reason for a group is to be able to share access to multiple
> tenants.  This is broken up into a handful of use cases:

Right, this is part of the problem, although you could consider it an
optimization. A very useful one though.

> 1.  All in one organization, multiple projects
> 2.  Users from a remote organization get mapped in to a local set of
> projects (but not all...)
> 3.  A virtual organization
>
>
>  I'd like to see the problems you are dealing with to evaluate if splitting
> groups from users makes sense.

My situation has several *completely independent* Openstack
deployments that wish to share a common identity service (also
preferably without having to log in to each, but that will be solved
later with federation).

Each user may or may not have the same access rights across each
deployment, hence the need to fine-tune roles/assignments. In the case
where multiple projects exist, are we going to have to specify an
assignment for each user to each project? It would be nicer to do this
through groups. I'm not sure which of the 3 cases of yours above this
maps to, but possibly all of them.

We could of course do this through a federated identity service, but
this then requires each user to be separately configured in the
federation group mapping which is very quickly going to get completely
untenable for large numbers of groups and users.  The mapping could
also map to local users, and that brings me back to the original
problem I raised at the start of the thread.

TL;DR
1. User assignments to projects will probably work for me.
2. Doing it with groups will be a lot nicer and easier to administer

Cheers
J

__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Matt Fischer]

On Fri, Jul 24, 2015 at 12:02 PM, Adam Young  wrote:

> On 07/24/2015 12:00 AM, Julian Edwards wrote:
>
>> Hello,
>>
>> I am relatively new to Openstack and Keystone so please forgive me any
>> crazy misunderstandings here.
>>
>> One of the problems with the existing LDAP Identity driver that I see
>> is that for group management it needs write access to the LDAP server,
>> or requires an LDAP admin to set up groups separately.
>>
>> Neither of these are palatable to some larger users with corporate
>> LDAP directories, so I'm interested in discussing a solution that
>> would get acceptance from core devs.
>>
>> My initial thoughts are to create a new driver that would store groups
>> and their user memberships in the local keystone database, while
>> continuing to rely on LDAP for user authentication. The advantages of
>> this would be that the standard UI tools could continue to work for
>> group manipulation.  This is somewhat parallel with ephemeral
>> federated user group mappings, but that's all done in the json blob
>> which is a bit horrible. (I'd like to see that working with a decent
>> UI some time, perhaps it is solved in the same way)
>>
>
> This has come up numerous times, as I am sure you are now aware by reading
> the rest of the thread.
>
> A couple points;  I've been aware of the hybrid driver for several years.
> I feel it is a security mistake to copy the users from the system of record
> (LDAP) into a cache (Keystone) and then tro only trust the values in the
> cache;  if I delete or disable a user in LDAP, that should be the state
> used, not the cached value.
>
>
Disabled and deleted user cannot bind to the LDAP server.
__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Adam Young]

On 07/24/2015 12:00 AM, Julian Edwards wrote:

Hello,

I am relatively new to Openstack and Keystone so please forgive me any
crazy misunderstandings here.

One of the problems with the existing LDAP Identity driver that I see
is that for group management it needs write access to the LDAP server,
or requires an LDAP admin to set up groups separately.

Neither of these are palatable to some larger users with corporate
LDAP directories, so I'm interested in discussing a solution that
would get acceptance from core devs.

My initial thoughts are to create a new driver that would store groups
and their user memberships in the local keystone database, while
continuing to rely on LDAP for user authentication. The advantages of
this would be that the standard UI tools could continue to work for
group manipulation.  This is somewhat parallel with ephemeral
federated user group mappings, but that's all done in the json blob
which is a bit horrible. (I'd like to see that working with a decent
UI some time, perhaps it is solved in the same way)


This has come up numerous times, as I am sure you are now aware by 
reading the rest of the thread.


A couple points;  I've been aware of the hybrid driver for several 
years.  I feel it is a security mistake to copy the users from the 
system of record (LDAP) into a cache (Keystone) and then tro only trust 
the values in the cache;  if I delete or disable a user in LDAP, that 
should be the state used, not the cached value.


Groups are tricky things.  While I've often toyed with what you suggest 
here, I always come back to the `group` being an identity attribute that 
exists outside of Keystone, and everything that we do inside of Keystone 
can be done with existing mechanisms in Keystone itself, especially now 
that we have Hierarchical Multitenantcy.


The most common reason for a group is to be able to share access to 
multiple tenants.  This is broken up into a handful of use cases:



1.  All in one organization, multiple projects
2.  Users from a remote organization get mapped in to a local set of 
projects (but not all...)

3.  A virtual organization


 I'd like to see the problems you are dealing with to evaluate if 
splitting groups from users makes sense.







However, one of the other reasons I'm sending this is to gather more
ideas to solve this. I'd like to hear from anyone in a similar
position, and anyone with input on how to help.

Cheers,
Julian.

__
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



__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Dave Walker]

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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Fox, Kevin M]

I think the issue is groups are very nice for managing sets of users through 
the web ui but users can only be in groups maintained by the same backend, and 
ldap backends tend to be readonly. It would be very handy if groups could 
include users from other domains. Maybe the db could be extended to support a 
domain column for groups?

Thanks,
Kevin


From: Steve Martinelli
Sent: Thursday, July 23, 2015 9:50:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] LDAP identity driver with groups from 
local DB


The LDAP driver for identity shouldn't require write access to look up groups. 
It'll only require write access if you want to allow Keystone to 
create/delete/update new groups.
Not sure what you mean by "requires an LDAP admin to set up groups separately" 
either. Have any more details you can share?

Thanks,

Steve Martinelli
OpenStack Keystone Core

Julian Edwards  wrote on 2015/07/24 12:00:33 AM:

> From: Julian Edwards 
> To: openstack-dev@lists.openstack.org
> Date: 2015/07/24 12:01 AM
> Subject: [openstack-dev] [keystone] LDAP identity driver with groups
> from local DB
>
> Hello,
>
> I am relatively new to Openstack and Keystone so please forgive me any
> crazy misunderstandings here.
>
> One of the problems with the existing LDAP Identity driver that I see
> is that for group management it needs write access to the LDAP server,
> or requires an LDAP admin to set up groups separately.
>
> Neither of these are palatable to some larger users with corporate
> LDAP directories, so I'm interested in discussing a solution that
> would get acceptance from core devs.
>
> My initial thoughts are to create a new driver that would store groups
> and their user memberships in the local keystone database, while
> continuing to rely on LDAP for user authentication. The advantages of
> this would be that the standard UI tools could continue to work for
> group manipulation.  This is somewhat parallel with ephemeral
> federated user group mappings, but that's all done in the json blob
> which is a bit horrible. (I'd like to see that working with a decent
> UI some time, perhaps it is solved in the same way)
>
> However, one of the other reasons I'm sending this is to gather more
> ideas to solve this. I'd like to hear from anyone in a similar
> position, and anyone with input on how to help.
>
> Cheers,
> Julian.
>
> __
> 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
>
__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Boris Bobrov]

On Friday 24 July 2015 09:29:32 Dave Walker wrote:
> On 24 July 2015 at 05:00, Julian Edwards  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?

-- 
Best regards,
Boris Bobrov

__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Matt Fischer]

On Fri, Jul 24, 2015 at 1:01 AM, Julian Edwards  wrote:

> On 24 July 2015 at 14:51, Matt Fischer  wrote:
> > Julian,
> >
> > You want this hybrid backend driver. Bind against LDAP for auth, store
> > everything else in mysql:
> >
> > https://github.com/SUSE-Cloud/keystone-hybrid-backend
> >
> > We maintain our own fork with has a few small differences. I do not use
> the
> > assignment portion of the driver and I'm not sure anyone does so keep
> that
> > in mind.
>
> Oh cool, I'll check that out, thanks for the pointer.  Ideally I'd
> like to get something in-tree, but this might be a good start.
>

I do have Ubuntu packaging code in my branch if that helps you deploy it at
all:

https://github.com/matthewfischer/keystone-hybrid-backend/



>
> > I know some of the Keystone team has pretty strong opinions about this
> but
> > it works for us.
>
> There's clearly a problem that needs solving, but I'd like to hear the
> opinions.
>
> > And nice to run into you again...
>
> Likewise!
>
> Cheers.
>
> __
> 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
>
__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Matt Fischer]

On Fri, Jul 24, 2015 at 1:10 AM, Henry Nash 
wrote:

> Matt,
>
> Your hybrid driver seems to be doing something different than what Julian
> was asking - namely providing some “automatic role assignments” for users
> stored in LDAP (unless I am not understanding your patch)?  I guess you
> could argue that’s a restricted version of being able to create group
> memberships outside of LDAP (which is Julian what I think you are asking
> for….), but probably a somewhat different use case?
>
> Henry
>


Henry,

First to clarify I don't want to call it my driver since the guys at SuSe
wrote it. It has 2 pieces, identity and assignment, we only use the
identity driver. AFAIK Assignment via LDAP is being deprecated anyway.
Since we have no ability to move users into LDAP groups and what not at our
company, we only use the driver I mentioned to do an LDAP bind and
everything else happens in mysql.




> On 24 Jul 2015, at 05:51, Matt Fischer  wrote:
>
> Julian,
>
> You want this hybrid backend driver. Bind against LDAP for auth, store
> everything else in mysql:
>
> https://github.com/SUSE-Cloud/keystone-hybrid-backend
>
> We maintain our own fork with has a few small differences. I do not use
> the assignment portion of the driver and I'm not sure anyone does so keep
> that in mind.
>
> I know some of the Keystone team has pretty strong opinions about this but
> it works for us.
>
> And nice to run into you again...
>
> On Thu, Jul 23, 2015 at 10:00 PM, Julian Edwards 
> wrote:
>
>> Hello,
>>
>> I am relatively new to Openstack and Keystone so please forgive me any
>> crazy misunderstandings here.
>>
>> One of the problems with the existing LDAP Identity driver that I see
>> is that for group management it needs write access to the LDAP server,
>> or requires an LDAP admin to set up groups separately.
>>
>> Neither of these are palatable to some larger users with corporate
>> LDAP directories, so I'm interested in discussing a solution that
>> would get acceptance from core devs.
>>
>> My initial thoughts are to create a new driver that would store groups
>> and their user memberships in the local keystone database, while
>> continuing to rely on LDAP for user authentication. The advantages of
>> this would be that the standard UI tools could continue to work for
>> group manipulation.  This is somewhat parallel with ephemeral
>> federated user group mappings, but that's all done in the json blob
>> which is a bit horrible. (I'd like to see that working with a decent
>> UI some time, perhaps it is solved in the same way)
>>
>> However, one of the other reasons I'm sending this is to gather more
>> ideas to solve this. I'd like to hear from anyone in a similar
>> position, and anyone with input on how to help.
>>
>> Cheers,
>> Julian.
>>
>> __
>> 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
>>
>
> __
> 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
>
>
>
> __
> 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
>
>
__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Dave Walker]

On 24 July 2015 at 05:00, Julian Edwards  wrote:
> Hello,
>
> I am relatively new to Openstack and Keystone so please forgive me any
> crazy misunderstandings here.
>
> One of the problems with the existing LDAP Identity driver that I see
> is that for group management it needs write access to the LDAP server,
> or requires an LDAP admin to set up groups separately.
>
> Neither of these are palatable to some larger users with corporate
> LDAP directories, so I'm interested in discussing a solution that
> would get acceptance from core devs.
>
> My initial thoughts are to create a new driver that would store groups
> and their user memberships in the local keystone database, while
> continuing to rely on LDAP for user authentication. The advantages of
> this would be that the standard UI tools could continue to work for
> group manipulation.  This is somewhat parallel with ephemeral
> federated user group mappings, but that's all done in the json blob
> which is a bit horrible. (I'd like to see that working with a decent
> UI some time, perhaps it is solved in the same way)
>
> However, one of the other reasons I'm sending this is to gather more
> ideas to solve this. I'd like to hear from anyone in a similar
> position, and anyone with input on how to help.
>

Hey Julian,

Can I suggest reading this excellent write up by Adam Young?
http://adam.younglogic.com/2013/10/read-only-ldap-in-keystone/

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 a side note, I had a comparable idea for an external AuthN driver
to plug into legacy RBAC systems but this area of Keystone wants to
focus on Federation rather than extending interaction at other levels.
You may fine the thread of interest:
http://lists.openstack.org/pipermail/openstack-dev/2014-October/048639.html

Thanks

--
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Henry Nash]

Matt,

Your hybrid driver seems to be doing something different than what Julian was 
asking - namely providing some “automatic role assignments” for users stored in 
LDAP (unless I am not understanding your patch)?  I guess you could argue 
that’s a restricted version of being able to create group memberships outside 
of LDAP (which is Julian what I think you are asking for….), but probably a 
somewhat different use case?

Henry
> On 24 Jul 2015, at 05:51, Matt Fischer  wrote:
> 
> Julian,
> 
> You want this hybrid backend driver. Bind against LDAP for auth, store 
> everything else in mysql:
> 
> https://github.com/SUSE-Cloud/keystone-hybrid-backend 
> 
> 
> We maintain our own fork with has a few small differences. I do not use the 
> assignment portion of the driver and I'm not sure anyone does so keep that in 
> mind.
> 
> I know some of the Keystone team has pretty strong opinions about this but it 
> works for us.
> 
> And nice to run into you again...
> 
> On Thu, Jul 23, 2015 at 10:00 PM, Julian Edwards  > wrote:
> Hello,
> 
> I am relatively new to Openstack and Keystone so please forgive me any
> crazy misunderstandings here.
> 
> One of the problems with the existing LDAP Identity driver that I see
> is that for group management it needs write access to the LDAP server,
> or requires an LDAP admin to set up groups separately.
> 
> Neither of these are palatable to some larger users with corporate
> LDAP directories, so I'm interested in discussing a solution that
> would get acceptance from core devs.
> 
> My initial thoughts are to create a new driver that would store groups
> and their user memberships in the local keystone database, while
> continuing to rely on LDAP for user authentication. The advantages of
> this would be that the standard UI tools could continue to work for
> group manipulation.  This is somewhat parallel with ephemeral
> federated user group mappings, but that's all done in the json blob
> which is a bit horrible. (I'd like to see that working with a decent
> UI some time, perhaps it is solved in the same way)
> 
> However, one of the other reasons I'm sending this is to gather more
> ideas to solve this. I'd like to hear from anyone in a similar
> position, and anyone with input on how to help.
> 
> Cheers,
> Julian.
> 
> __
> 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 
> 
> 
> __
> 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

__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Julian Edwards]

On 24 July 2015 at 14:51, Matt Fischer  wrote:
> Julian,
>
> You want this hybrid backend driver. Bind against LDAP for auth, store
> everything else in mysql:
>
> https://github.com/SUSE-Cloud/keystone-hybrid-backend
>
> We maintain our own fork with has a few small differences. I do not use the
> assignment portion of the driver and I'm not sure anyone does so keep that
> in mind.

Oh cool, I'll check that out, thanks for the pointer.  Ideally I'd
like to get something in-tree, but this might be a good start.

> I know some of the Keystone team has pretty strong opinions about this but
> it works for us.

There's clearly a problem that needs solving, but I'd like to hear the opinions.

> And nice to run into you again...

Likewise!

Cheers.

__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Julian Edwards]

On 24 July 2015 at 14:50, Steve Martinelli  wrote:
> The LDAP driver for identity shouldn't require write access to look up
> groups. It'll only require write access if you want to allow Keystone to
> create/delete/update new groups.
> Not sure what you mean by "requires an LDAP admin to set up groups
> separately" either. Have any more details you can share?

Hi Steve

Assuming LDAP access is read-only, group info would need to be set up
in the LDAP server itself prior to keystone accessing it.  This is not
something that many large corporations would be willing to
accommodate, which means you'd need to get group data from elsewhere.
Hence, my suggestion!

__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Steve Martinelli]

The LDAP driver for identity shouldn't require write access to look up
groups. It'll only require write access if you want to allow Keystone to
create/delete/update new groups.
Not sure what you mean by "requires an LDAP admin to set up groups
separately" either. Have any more details you can share?

Thanks,

Steve Martinelli
OpenStack Keystone Core

Julian Edwards  wrote on 2015/07/24 12:00:33 AM:

> From: Julian Edwards 
> To: openstack-dev@lists.openstack.org
> Date: 2015/07/24 12:01 AM
> Subject: [openstack-dev] [keystone] LDAP identity driver with groups
> from local DB
>
> Hello,
>
> I am relatively new to Openstack and Keystone so please forgive me any
> crazy misunderstandings here.
>
> One of the problems with the existing LDAP Identity driver that I see
> is that for group management it needs write access to the LDAP server,
> or requires an LDAP admin to set up groups separately.
>
> Neither of these are palatable to some larger users with corporate
> LDAP directories, so I'm interested in discussing a solution that
> would get acceptance from core devs.
>
> My initial thoughts are to create a new driver that would store groups
> and their user memberships in the local keystone database, while
> continuing to rely on LDAP for user authentication. The advantages of
> this would be that the standard UI tools could continue to work for
> group manipulation.  This is somewhat parallel with ephemeral
> federated user group mappings, but that's all done in the json blob
> which is a bit horrible. (I'd like to see that working with a decent
> UI some time, perhaps it is solved in the same way)
>
> However, one of the other reasons I'm sending this is to gather more
> ideas to solve this. I'd like to hear from anyone in a similar
> position, and anyone with input on how to help.
>
> Cheers,
> Julian.
>
>
__
> 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
>__
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

Re: [openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Matt Fischer]

Julian,

You want this hybrid backend driver. Bind against LDAP for auth, store
everything else in mysql:

https://github.com/SUSE-Cloud/keystone-hybrid-backend

We maintain our own fork with has a few small differences. I do not use the
assignment portion of the driver and I'm not sure anyone does so keep that
in mind.

I know some of the Keystone team has pretty strong opinions about this but
it works for us.

And nice to run into you again...

On Thu, Jul 23, 2015 at 10:00 PM, Julian Edwards  wrote:

> Hello,
>
> I am relatively new to Openstack and Keystone so please forgive me any
> crazy misunderstandings here.
>
> One of the problems with the existing LDAP Identity driver that I see
> is that for group management it needs write access to the LDAP server,
> or requires an LDAP admin to set up groups separately.
>
> Neither of these are palatable to some larger users with corporate
> LDAP directories, so I'm interested in discussing a solution that
> would get acceptance from core devs.
>
> My initial thoughts are to create a new driver that would store groups
> and their user memberships in the local keystone database, while
> continuing to rely on LDAP for user authentication. The advantages of
> this would be that the standard UI tools could continue to work for
> group manipulation.  This is somewhat parallel with ephemeral
> federated user group mappings, but that's all done in the json blob
> which is a bit horrible. (I'd like to see that working with a decent
> UI some time, perhaps it is solved in the same way)
>
> However, one of the other reasons I'm sending this is to gather more
> ideas to solve this. I'd like to hear from anyone in a similar
> position, and anyone with input on how to help.
>
> Cheers,
> Julian.
>
> __
> 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
>
__
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

[openstack-dev] [keystone] LDAP identity driver with groups from local DB

[Julian Edwards]

Hello,

I am relatively new to Openstack and Keystone so please forgive me any
crazy misunderstandings here.

One of the problems with the existing LDAP Identity driver that I see
is that for group management it needs write access to the LDAP server,
or requires an LDAP admin to set up groups separately.

Neither of these are palatable to some larger users with corporate
LDAP directories, so I'm interested in discussing a solution that
would get acceptance from core devs.

My initial thoughts are to create a new driver that would store groups
and their user memberships in the local keystone database, while
continuing to rely on LDAP for user authentication. The advantages of
this would be that the standard UI tools could continue to work for
group manipulation.  This is somewhat parallel with ephemeral
federated user group mappings, but that's all done in the json blob
which is a bit horrible. (I'd like to see that working with a decent
UI some time, perhaps it is solved in the same way)

However, one of the other reasons I'm sending this is to gather more
ideas to solve this. I'd like to hear from anyone in a similar
position, and anyone with input on how to help.

Cheers,
Julian.

__
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