Open maximann opened 5 years ago
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:
Is there typically any additional steps made to retrieve details about the user and the groups associated with the user?
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.
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.
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.
@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
-> 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).
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.