I too have a genuine interest in getting Turbine to work with Ldap. I have mentioned this once or twice on the list and briefly discussed this with Jason. However due to higher priorities I haven't actually got round to doing anything about it *ashamed*
The code that was once donated wasn't really up to scratch and has since been removed. Perhaps it's once again time to throw around a couple of ideas to see if we can work something out and get *something acceptable* up & running. Mitch would you be willing to work on this with me? Some input from other members would be beneficial to reach the best solution & increase acceptance when it comes. For example is it an idea to try and have a (JNDI) adaptor based roughly on the same style as the DB adaptors? Making use of a common connectionPool mechansim? Peer integration? Or should we keep the JNDI stuff seperate from the DB stuuf altogether??? I'm trying to think along the lines that it should be pluggable and transparent to the app. programmer, so instead of querying a DB it's an Ldap server you're querying. Input sought & appreciated. Mitch perhaps we could take our discussion off-line to see what we can come up with. /Colin ----- Original Message ----- From: "Mitchell Christensen" <[EMAIL PROTECTED]> To: "'Turbine Developers List'" <[EMAIL PROTECTED]> Sent: Saturday, February 02, 2002 12:52 AM Subject: RE: LDAP Authentication > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
