settingsLogin | Registersettings

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

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jul 24, 2015 in openstack-dev by Julian_Edwards (260 points)  

14 Responses

0 votes

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 bigjools@gmail.com wrote on 2015/07/24 12:00:33 AM:

From: Julian Edwards bigjools@gmail.com
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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Steve_Martinelli (6,500 points)   1 3 6
0 votes

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 bigjools@gmail.com 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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Matt_Fischer (9,340 points)   1 4 8
0 votes

On 24 July 2015 at 14:50, Steve Martinelli stevemar@ca.ibm.com 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Julian_Edwards (260 points)  
0 votes

On 24 July 2015 at 14:51, Matt Fischer matt@mattfischer.com 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Julian_Edwards (260 points)  
0 votes

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 matt@mattfischer.com 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 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 <bigjools@gmail.com bigjools@gmail.com> 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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Henry_Nash (1,080 points)   2
0 votes

On 24 July 2015 at 05:00, Julian Edwards bigjools@gmail.com 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Dave_Walker (3,660 points)   1 4
0 votes

On Fri, Jul 24, 2015 at 1:10 AM, Henry Nash henryn@linux.vnet.ibm.com
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 matt@mattfischer.com 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 bigjools@gmail.com
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-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Matt_Fischer (9,340 points)   1 4 8
0 votes

On Fri, Jul 24, 2015 at 1:01 AM, Julian Edwards bigjools@gmail.com wrote:

On 24 July 2015 at 14:51, Matt Fischer matt@mattfischer.com 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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Matt_Fischer (9,340 points)   1 4 8
0 votes

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

--
Best regards,
Boris Bobrov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Boris_Bobrov (1,720 points)   1 3
0 votes

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 bigjools@gmail.com wrote on 2015/07/24 12:00:33 AM:

From: Julian Edwards bigjools@gmail.com
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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jul 24, 2015 by Fox,_Kevin_M (29,360 points)   1 3 4
...