Enforcing groups from LDAP
Jean-Francois Beaumont
jean-francois.beaumont at mail.mcgill.ca
Fri Apr 10 14:06:21 EDT 2015
Hi Mads,
Thanks for your reply. With my limited knowledge of the source code, I
suspect this was already implemented
in kallithea/lib/auth_modules/__init__.py.KallitheaExternalAuthPlugin. This
class calls UserGroupModel().enforce_groups in its _authenticate function.
The foreign LDAP groups are then managed automatically and added to the
database with the description "Automatically created from plugin:ldap".
Moreover, if I add a user to a LDAP group he is not a member of, Kallithea
will make sure the user is removed from that group if not provided by LDAP
when that user logs in. The groups get created if needed but are not
deleted if they are empty, which make sense to me as you might have
permissions for that group.
I've created the following patch to expose this in the UI and returning the
LDAP groups to the framework. Not claiming this is final work by any mean
but minimally, it works:
https://bitbucket.org/jfbeaumont/kallithea/commits/6cc72bef379ce1df856ed5f8b6f4b9661f661c57
In the UI, I set the new group attributes to:
Groups Attribute: memberOf
LDAP search Filter for groups:OU=Distribution,OU=Corp
Groups,DC=company,DC=com
Hope that helps,
JF
2015-04-10 12:21 GMT-04:00 Mads Kiilerich <mads at kiilerich.com>:
> On 04/10/2015 11:23 AM, Jean-Francois Beaumont wrote:
>
>> Hi,
>>
>> I've been searching for a way so Kallithea preserves the groups from LDAP
>> and didn't find how to achieve this from the configuration alone. However,
>> I see all the code that is necessary to achieve that is there and all
>> lib/auth_modules/auth_ldap.py needs to do is to add a 'groups' to
>> user_attrs so this would be done.
>>
>> So I've written some code to expose this in Kallithea but it looks so
>> easy that I'm wondering if the feature is not actually implemented and I've
>> simply overlooked something in the documentation.
>>
>> Otherwise, if people are interested, I would be glad to contribute a
>> patch.
>>
>
> I think you are right it hasn't been implemented upstream.
>
> One problem with this (and other use of external sources for user
> information) is to figure out which source is authoritative and/or how to
> synchronize. For group memberships, it is nice to be able to see in the
> Kallithea web interface exactly who have access through a group. That
> problem could probably be mitigated by making sure to synchronize all user
> memberships when the user logs in ... and when looking at a user group ...
> and when looking at permissions for a repo where a group has access. But
> how to handle the case where users were given access through LDAP but was
> removed from the group again? Or when the user has been granted access in
> Kallithea instead of in LDAP?
>
> A good solution would require redefining the problem somewhat ... or at
> least make it clear which trade-off you make. (From your description it
> seems like you define the problem differently than I did here and accept
> that the Kallithea UI doesn't give the full answer. That might be ok.)
>
> I look forward too see how you have solved the problem!
>
> /Mads
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20150410/e456b4db/attachment.html>
More information about the kallithea-general
mailing list