Hey Eric, You are correct. The most recent list of JNDI service providers (http://java.sun.com/products/jndi/serviceproviders.html#12) includes LDAP, COS Naming, RMI Registry, NIS, DSML, DNS, File System, Novell and the Windows Registry. I think that a JNDISecurityService is the way to go, but you're right, I should probably focus on the LDAPSecurityService given my schedule and make it LDAP specific.
I did send a message directly to Jason, and one other (I don't remember which) 2+ days ago and recieved no response. Hopefully they'll hit this discussion and want to get involved. I think that in the meantime I'll subclass LDAPUserManager and LDAPSecurityService and get things working like that. Once that works, I'll share those files and we can discuss how to best implement the changes within Turbine. Sound reasonable? -Mitch PS I'm all for a better "long-term" solution, and would be interested in participating, time permitting. -----Original Message----- From: Eric Dobbs [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 3:22 PM To: Turbine Developers List Subject: Re: LDAP Authentication On Friday, February 1, 2002, at 02:49 PM, Mitchell Christensen wrote: > After looking at the code, I'm wondering if this shouldn't be > implemented using the om/peer model, but that is meant solely for RDBMS > right now (correct? Its a different discussion altogether, but why can't > objects be mapped to LDAP as well?). For now I was thinking about > simply > putting the JNDI calls directly in the LDAPSecurityService. Couple things. om/peers are definitely DB biased right now. There has been some talk of abstracting that to support an XML backend, and I think your suggestion of LDAP is not unreasonable in the context of that discussion. I suspect that is a bigger project than your specific need calls for. I don't have much experience with JNDI nor LDAP. My intuition is that a JNDISecurityService would be more generally useful than something specific to LDAP. Your coment about JNDI calls leads me to believe you have experience to verify whether my intuition is correct or not. I understand there exist JNDI adaptors for NIS+, and LDAP, and others... might just be another case of "a small amount of knowledge can be dangerous." 8^) In any case, JNDI calls in the LDAPSecurityService sounds like the shortest route at the moment. > Also, the current implementation won't bind (authenticate) against > Netscape > Directory Server. I understand the problem, but won't go into it here > because it is somewhat long-winded. There will need to be a change or > two > to the LDAPUserManager as well. No surprise that LDAPUserManager needs work. It's part of the whole bundle that was abandoned in Turbine's CVS repository. Your attention to the matter will be very welcome. > Would it be fare to ask for a brain dump from anyone who has thoughts > on how > this should be done in exchange for building the LDAP interface and > submitting? I noticed that Jason van Zyl, Leonard Flournoy, Tracy > Adewunmi > and Rafal Krzewski were listed as original authors. Are they still > around? > Is there some original design notes, etc. that might be of use? JvZ is definitely around, but very busy on lots of other projects. I think he's presently traveling but I'm sure he'll add to the conversation when he gets back. The rest I can't say. Colin Chalmers and some of his colleagues have discussed this before on the turbine-user list. I remember some discussion about an LDAP schema and DNs and such (exposing more ignorance, I know 8^). Here's a link to the archive that should get you too the relevant thread. http://www.mail-archive.com/turbine- user%40jakarta.apache.org/msg02150.html Paul Esposito's name is one this one. I am fairly certain that nothing ever came of this thread (or the LDAP stuff would be working now). It might be worth firing an email off to those two to see if they have any time they can offer to help. They have at least have more experience to bring in this area. I'm happy to lend a hand (maybe it'll give me an excuse to finally learn LDAP and JNDI 8^). > I'm going to cross-post this to turbine-dev since that is probably where > this thread should be anyways. good move. this is definitely the right place for the conversation. -Eric -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
