`allowed_groups` are looked up with authenticated user instead of search user

Bug description

The plugin uses a so called search user to lookup the dn of the user to be authenticated. The authentication is done using an ldap bind which creates another connection to the server. All subsequent ldap searches are performed with the connection of the authenticated user and not with the connection of the configured search user. Thus, the ldap query to check each of the allowed_groups is performed with the authenticated user instead of the search user.

The real problem behind this behavior: the authenticated user needs the ldap permissions to lookup the ldap groups. I think it’s more the role of the search user to have such permissions instead of the authenticated user. Our institution follows such a consequent security approach where ldap groups are used for authorization by member check. But there is no need that the groups are itself accessible by the members.

Expected behaviour

I would expect that all search operations use the connection established with the search user.

Actual behaviour

After successful authentication, all ldap operations are done with the authenticated user instead of the search user.

How to reproduce

A source review targeting the following aspects or any working setup with debugger or debug output reveals this behavior.

method authenticate: - calls resolve_username to use the search user to lookup the dn of the user to be authenticated - later the variable conn is initialized with a get_connection method call with the user to be authenticated - search_filter and allowed_groups queries use the connection (conn) with the successfully authenticated user

Your personal set up

• Jupyterhub 1.2.1 with ldap authenticator (customized the official docker image)

How to proceed

I feel confident to fix this issue in a non intrusive way of keeping both connections to the ldap server and introduce a config flag which could be switched on to use the connection with the search user instead of the user to be authenticated.

Is such a contribution desired by the project? Or is the actual behavior the one which is expected by the project? I just ask as there are some pull request open from two years back.

[tobi45]

@manics Thanks for your quick answer! I totally understand that situation. And it sounds promising to me. Let’s start with that issue and see how things evolve 😀

[tobi45]

Hey guys, just to prevent confusion: I closed PR #185 and opened its replacement #207. Background: I throw the old repo fork away and created a new one with a new structure allowing me to manage my changesets better.

Please let me know If I could be of any help.