LDAP DataConnecter attribute resolver cache collision

[Jeffrey Eaton]

I just got a report of a user saying that when logging into a particular app, they were greeted with another user's name.  

After doing a lot of debugging, I tracked this down to the LDAP DataConnector in the attribute resolver doing caching in a completely broken way.  When an LDAP result is cached by the ResultCache, the cache key used is the Java hashCode of the search filter.  Digging into how that's actually generated in org/ldaptive/SearchFilter.java and in org/ldaptive/LdapUtils.java, it's essentially just the hashCode value of the string representation of the search string and of the parameters passed.

In my case, the LDAP searchFilter is (uid=$requestContext.principalName), and the parameters is empty. For two users with the principalName of dlo1 and dn11, the hashCode comes out to the value of 1877686529 for both.  This means that if dlo1 logs in, then before the cache expires, dn11 logs in, dn11's attributes are actually dlo1's.

This is very, very bad for any system which actually depends on the values of the released attributes.

As a workaround, I am disabling the ResultCache on my LDAP DataConnector. 

Given the security-sensitve nature of this bug, I think it would be prudent for anyone using the LDAP DataConnector and ResultCache to do the same.

-jeaton