Re: [Acegisecurity-developer] LDAP Dao Status

[Robert Sanders]

Joseph,     I'm glad that it looks like someone will finally get the time to look at the LDAP code.     The InitialDirContextFactory is basically a wrapper bean to create JNDI connections, so it really is (or should be) agnostic as to how you do user authentication.  I agree that it is probably cleaner to use composition rather than inheritance.  Basically the InitialDirContextFactory boils down to 3 cases: 1) anonomous bind against the LDAP server followed by user lookup; 2) use of a manager username/password to bind followed by user lookup; 3) use of username to both bind and as a by-product authenticate.      In addition to the HEAD, you should probably look at the "ldap_refactor_07-20-2005" tag (for the providers/dao/ldap directory), as that was where I playing around with my latest ideas before I ran out of time to work on Acegi.  My usecase is different than your's, and I'm not really sure how prevalent either one is.  My usecase is that I have multiple sub-contexts for different categories of users within "my" LDAP server under which different sets of users are stored; I'd like to be able to authenticate against a subset of these contexts so I don't just want to search the whole parent tree everytime, just the particular sub-contexts from which user's would have access.  I suspect that there is more than one way to do this, but I'd like to be able to do so as concisely as possible (with consideration also going to clarity).  If you do have any questions I'd be happy to try an answer them; just keep in mind that I've been working on non-Java related projects since late spring, so I'm a bit out-of-touch with the code at the moment. Joseph Dane wrote: I've been going over the LDAP DAO stuff, and I thought I'd send some notes out before I actually start any work. Which isn't, unfortunately, to say that I positively will be able to work on this. Time constraints, and all that. Also, I know that the current state is meant to be a simplification of some of the previous work, which I agree was necessary, but I think we need to at least enable some of the different ways people use LDAP. Also, I should be clear that the particular situation in which I want to use LDAP+Acegi might not be typical. I'm not really sure. I have a situation where authentication is *mainly* performed via LDAP, but where authorizations are mainly kept elsewhere. So I need a chance to add authorities not represented in LDAP. I also need a way to perform "fallback" authentication, in case LDAP is unavailable. I'd be happy if the default setup read authorizations strictly from LDAP, and there was no fallback authentication, but I do need them to be available. So, with that here are some notes: 1. The main class, LdapPasswordAuthenticationDao (which I'll just call LPAD below) now inherits from an InitialDirContextFactoryBean. I take it this superclass is meant to do the LDAP connection/search. But there are many different strategies for this, and having a single superclass doesn't seem like the best way to enable variant approaches. I'd rather have a separate class which plugs into the LDAP to do the search. We can provide a couple of concrete implementations, including a "basic" bind, a "manager" search+bind, and maybe something for AD. 2. the current LPAD has a getRolesFromContext() method which returns String roles names from an LDAP context. perhaps we could have a getRoles(), the default implementation of which delegates to getRolesFromContext(), but which can be overridden. 3. if we included a stub method to attempt local authentication, my requirement for a fallback auth method would be fulfilled. something like public UserDetails loadUserByUsernameAndPassword(String u, String p) { UserDetails user = loadLdap(u, p); if (user == null) { user = loadLocally(u, p); } } that's it for now. hopefully Robert and the other authors of the sandbox version are around to comment on this. in any case, I'll try to get some actual work done on this later this week.