Enforcing groups from LDAP

Sun May 10 09:57:16 EDT 2015

Hi Jean-Francois (and everyone else),

I'm attempting to use the patch for using groups that you provided here
https://bitbucket.org/jfbeaumont/kallithea/commits/6cc72bef379ce1df856ed5f8b6f4b9661f661c57

but at present I am unable to get the system to do anything with the LDAP
groups functionality and I would appreciate your advice upon how you
expected it to work (or is working in your installation).

My suspicion is that:

   - I have an incorrect group filter specified
   - the code assumes a two way navigation between users-> groups and vice
   versa (groups-> users) whereas my LDAP only has groups-> users (my LDAP has
   no actual attributes to do this but it does have "operational attributes"
   that support this - as would seem logical)

I'm a Java Dev by training so my grasp of python isn't that great and the
extensive use of dictionaries makes it hard for me to follow just what is
being returned where (eg attrs)

I can authenticate using LDAP as normal users (so the LDAP connection and
filters are AOK for users). I'm uncertain for the groups though if it is
working as expected - ie the group configuration is correct or if it is not
working as I expected.
I am using an OpenDJ (OpenDS fork) and my LDAP group configuration is:

   - Groups Attribute: memberOf

   - LDAP Search Filter for groups: (objectClass=groupOfUniqueNames)

The above group search filter works AOK within Apache Directory Studio for
filtering the LDAP and returning all of the groups contained therein.

What exactly does the "Groups Attribute" represent? Is it the attribute
upon the user that allows navigating from the user to the group? or is it
an attribute of the Group that allows navigating back to the user?

You mentioned that this was "minimally working". What do you mean by
minimally working? You can start with an empty Kallithea, point it to the
your LDAP, configured appropriately, and as your users login to the system
both their account and the associated groups get populated into Kallithea?
Or perhaps something else?

I just tried amending line 379/380 as follows:

            log.info('user %s authenticated correctly'
%user_attrs['username'])
            log.debug('all group details %s' %user_attrs)

And it produces output like this

2015-05-10 23:16:02.091 INFO  [kallithea.lib.auth_modules.auth_ldap] user
todd.morgan authenticated correctly
2015-05-10 23:16:02.091 DEBUG [kallithea.lib.auth_modules.auth_ldap] all
group details {'username': u'todd.morgan', 'active': True, 'extern_type':
'', 'firstname': u'Todd', 'admin': False, 'lastname': u'Morgan', 'groups':
[], 'email': 'todd.morgan at bigcorp.com.au', 'active_from_extern': None,
'extern_name': 'cn=todd.morgan,dc=bts,dc=bigcorp,dc=com,dc=au'}

The groups': [] would suggest that nothing is coming back from the LDAP.

Does your code assume anything about the LDAP user and group relationship?
ie that you can navigate from the user to the group and vice versa?

>From what I can see in my LDAP the user has nothing linking them to groups
directly in their attributes

and the group has an attribute "uniqueMember" which is a list of the CNs
for all of the contained users. So it is a one-way relationship, with
operational attributes to support bi-directional navigation.

I already tried using "uniqueMember" as the groups attribute field (with
the same result). The current values (ie above) are taken from our CROWD
installation which sits on top of the same LDAP and it uses the same
"memberOf" attribute that you are using.

Hope you can help :- )

Thanks for your time

> 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/20150510/379336ae/attachment-0001.html>