ldap authentication

Mon, Sep 6, 2004

I’ve been playing around with LDAP authentication inside the Bodington VLE, which we use as CLAN. Sometimes it can seem to take ages to let you in. So, I made 3 enhancements to the code, one which was staring me in the face all the time and the other two a bit less obvious to the un-coffeed and pizza-less :)

  • I’ve been storing the DN of the user in Bodington as an AliasEntry, so when they log in for the first time and Siva creates their account, it also effectively gives them another ID - their DN, e.g. cn=Test User,ou=Test Site,ou=Test Org. What the LDAP authenticator has been doing, is binding to the LDAP store as a privileged user, with enough rights to browse for the CN attribute and doing a lookup to find the user’s DN. Efficiency here was easy. If the user exists in the Bodington database, get their DN direct from their AliasEntry. Then, it’s a trade-off - Will the user and alias lookups withing Bodington be quicker than the LDAP lookup? More than likely
  • The next efficiency gain was to replace an attribute compare operation with a straight bind operation. Attribute comparisons seem to be around 5-10 times slower than binding. This, of course, is of no help if you want to compare, say, names, or email addresses but I was using it to do a compare on the userPassword attribute. It’s much much faster just to bind using the user’s DN and let the exception catch a failed authentication, rather than constructing an LDAPAttribute object with the userPassword and comparing it with what’s on the server
  • The final efficiency gain was a little less obvious. It seems that when you do an LDAP search, the server doesn’t return all the results at the same time. Rather, you have to cycle through the result object, until it reports that it’s done. It also involves a round trip to the LDAP server to get each result object in the chain. Again, this can’t be helped if you have multiple search results to take into account but when we’re searching for a user DN and nothing else, then we can be sure that if the search succeeded, the our DN will already be local, having come back from the server in the first result object. So, there’s no need to go looking for more. Even if there are multiple DNs returned, that means there is something wrong with the user info in the LDAP store as the same CN should never point to more than one DN

So, hopefully, these little changes will make a big difference, especially at times of high network load, when the traffic to the server can be kept to a minimum

comments powered by Disqus