in LdapAuthorizationPolicy, the "ldap.authorizeField" is ignored. In fact it is got from LDAP but not used to gather the logins that may authorized a selected username.
patch which needs review: http://www.igniterealtime.org/community/servlet/JiveServlet/download/202050-5227/openfire-ldap-auth-policy.diff.zip
Openfire + LDAP
Speedy, you have any thoughts on this?
Asked on the forums about the need for this patch.
I cannot access the forums since my account has been disabled (I don't know why), however, do you really think that after six years of an unpatched bug, I'm still working on the same issue and at the same place?
At the time, we fixed the problem with a local patch (I don't remember exactly the problem, but it was definitely a hack). Sincerely I don't know the current situation since I left that place at the end of 2010.
So... do whatever you wish. I made a patch, I did my best to help.
Greetings,
1) I have fixed your forums account, so please try using it now.
2) I don't know if you were still using this patch with current Openfire 4.0.3 release, which is why I asked.
3) We are all volunteers here and have near zero LDAP expertise, so having a current user report that this patch is necessary, goes a long ways to getting it currently merged.
I'll PR this change and see if anybody has comments for review. Sorry.
Hello Daryl
sorry for being harsh. Anyway I really forgot what happened at the time.
Anyway, the fix is a one-liner and for a specific problem, i.e. an LDAP field that has been ignored in favour of another.
Looking at the current code it seems that the bug is still there:
https://github.com/igniterealtime/Openfire/blob/master/src/java/org/jivesoftware/openfire/ldap/LdapAuthorizationPolicy.java#L98
I will try to get as much as possibile from memory.
The problem is that:
1. I make a login through SSO with a web-based client (Hablar)
2. IIRC the login to LDAP is made by a sort of superuser that can impersonate anyone
3. The correct code should read the field confìgured via ldap.authorizeField to obtain a collection of authorizable principals.
Instead, the code currently only reads the name field.
So, IMHO, the bug is still there.