Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LDAP Integration does not use Bind #131

Open
maximann opened this issue Feb 5, 2019 · 5 comments
Open

LDAP Integration does not use Bind #131

maximann opened this issue Feb 5, 2019 · 5 comments

Comments

@maximann
Copy link

maximann commented Feb 5, 2019

It looks like the current LDAP integration of kafka-webview wants to retrieve the user password property and compare locally. This is a somewhat odd requirement, since most LDAP servers are setup to not return the password, especially not in a hashed and salted form that corresponds to the Spring LDAP encoder.

Instead, most projects make use of the LDAP bind functionality, which gives the server authority to make the authentication decision.

@Crim
Copy link
Collaborator

Crim commented Feb 7, 2019

Hey thanks for bringing this up, as I'm not super familiar w/ LDAP. Basically what you're describing is a flow that looks like:

  • User enters credentials in web app
  • Server takes those credentials and attempts to bind/connect to LDAP using them.
  • If LDAP rejects the credentials, user is NOT authenticated.
  • If LDAP accepts the credentials, user IS authenticated.

Is there typically any additional steps made to retrieve details about the user and the groups associated with the user?

@maximann
Copy link
Author

maximann commented Feb 7, 2019

Thanks for getting back so quickly. I'm no LDAP expert myself, I just tried to integrate webview with our server and came across the problem here. The flow you describe is accurate. My impression is that during the bind process additional details about the user can be retrieved such as group membership.

From my current understanding, one important thing is that "ldaps://" is used when sending passwords in plaint text, and the LDAP server needs to be setup to support this.

It sounds like spring supports this process natively, I found the following two resources:
https://docs.spring.io/spring-security/site/docs/3.0.x/reference/ldap.html
https://stackoverflow.com/questions/5255158/spring-ldap-bind-for-successful-connection

All this being said, I don't know much about LDAP myself, so take this with a grain of salt.

@Crim
Copy link
Collaborator

Crim commented Feb 14, 2019

Yea, let me do some research and understand the most common way ldap is integrated. I followed this tutorial which may or may not have been the best reference.

@Crim
Copy link
Collaborator

Crim commented Feb 14, 2019

So digging it looks like SpringBoots out of the box LDAP integration supports two modes of integration:

For LDAP servers with anonymous access, it connects anonymously and searches for a matching user record. I imagine this use case is not very common.

For LDAP servers that do NOT have anonymous access, you provide a management userDn and password. SpringBoot's integration will bind using these credentials, and then perform the user look as described above.

What has been described in this issue would be a third mode, where the user supplied credentials are used to bind to LDAP. Assuming LDAP accepts those credentials and the bind is successful, the above search would be performed to find the matching user's groups. From looking online it appears as tho this is not supported out of the box, but likely possible to implement with a bit of custom coding.

@OlivierTarnus
Copy link

@Crim ,

Your analysis is right for connecting to the LDAP server: the application need to authenticate if server doesn't allow anonymous binding.

The problem here is more to actually authenticate the users connecting to kafka-webview, and more precisely to overcome the limit imposed by most seriously configured LDAP servers: you can't retrieve password hashs, so no local compare is possible within kafka-webview.

The most common way to get around this is exactly what you described before::
_* User enters credentials in web app

  • Server takes those credentials and attempts to bind/connect to LDAP using them.
  • If LDAP rejects the credentials, user is NOT authenticated.
  • If LDAP accepts the credentials, user IS authenticated._

-> In this context, there is no need to use a separate Bind DN for the application itself...

Once you are connected as this user, you can query his group membership (for Active Directory, all the memberOf fields of the user record).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants