[Acegisecurity-developer] LDAP Dao Status

[Robert r. Sanders]

After a couple false starts which in retrospect I shouldn't have checked into the CVS HEAD, I have finally cleaned up the code and gotten an updated version of the LDAPPasswordAuthenticationDao, along with a unit test, into the CVS HEAD.  I will post a similar message to the forums, but if anyone is interested in trying out the code and providing feedback, please do; in particular I haven't figured out how to test Active Directory style logins (when the login name is [EMAIL PROTECTED]). After struggling to complete this code I have come to the sad realization that I simply don't have enough time in the day for everything I'd like to do.  When I initially began working on the LDAP integration for Acegi, I was anticipating using it in an upcoming project; however that project has continued to be pushed off onto the back burner, and I find the time I am able to work on Acegi severely limited.  I am still willing to help out; but I am simply unable to put in any more time than I already am, meaning that if LDAP is to be completed in a reasonable time frame someone else is going to have to work on it.  I will help out as much as possible; however those of you monitoring the rate of progress on the LDAP code in recent months can see that that is not much.  The following are my current thoughts on the status of the LDAP code: 1. JNDI is a real pain; but it is the only solution that doesn't involve extra libraries; therefore the LDAP code should stick with JNDI if at all possible. 2. It is seems to me that given the complex ways in which LDAP Directories can be designed, that there are 3 possible solutions for the LDAP integration code to be able to solve everyone's problems:     2.a Split the LDAP Dao into 2 different Daos: the first would be implement a 'basic' approach for people with straight forward directory layouts (like the latest version of the LDAP Dao currently does), the second would be an 'advanced' approach which would require more configuration but give the user pretty much any option they want as far as configuration.     2.b Find or create a simplified LDAP query language (LDAP already has something fairly ugly, but usable, I just don't know of any existing LDAP URL Query -> JNDI conversion utilities).  The idea would be to allow user's with straight forward LDAP configurations to have easy to understand, straight forward configurations; while allowing user's who need it the power to configure their settings however they need them.     2.c The most appealing alternative is for someone to come up with an interface which uses sensible defaults to keep most configurations down to a few properties, while still allowing advanced users the power they want. 3. Ben suggested removing the PasswordAuthenticationDao interface; for some setups this would be as easy as using one of the existing PasswordEncoder implementations; however, other directories are configured so that the the user can only verify (but not actually read) their password, this situation should be solvable by storing the LDAP connection settings in a ThreadLocal and using a special PasswordEncoder which actual does a bind/login on the LDAP Server to test the password.  I don't know how common this situation is, as I am by no means an expert on LDAP, but it seems to me there is a reason that many LDAP authentication solutions implement authentication by "passing the buck" to the LDAP server. 4. One decent source of ideas is the Apache mod_auth_ldap, which provides an interesting source of comparisons to the existing Java JNDI based authenticators. -- Robert r. Sanders Chief Technologist iPOV (334) 821-5412 www.ipov.net