John: Sorry I have been really busy and have not had a chance to followup on my emails. The original author of the sdk is actually back doing continuing work on it. Yes indeed you can replace the ldap provider with the one from iplanet and it gets you much better session and connection recovery.
I actually spent a bit of time working on a native ldap implementation, not using jndi, and put in conn pooling and other features. I think I would like to look at rolling these into the base line jndi implementation as well and leave folks with an option to choose either realm implementation they would like to use with tomcat. How about I pick up the jndi module and work on it a bit to get some of these features in. BTW if you want to take a look at the native ldap realm module you can grab it from my web site. http://www.dahbura.com/ldap I thought if folks liked it and wanted to use it we could include it in the base build for tomcat. Should I just take the current snapshot in there and work on it or does it need to be checked out? Tony John Holman wrote: > At 21:41 04/01/02, Tony Dahbura wrote: > >John: > >There are other issues with the JNDI implementation that we have run into > >with some > >commercial high end load balancers. It has to do with connection > >re-authentication > >and sessions getting dropped on non used connections. > > I did some work on the actual > >API for the Netscape LDAP implementation and we puti n handling of this > >situation > >as well. It really from a programmer perspective looks the same but > >handles a lot > >of low level details with regards to server connections that work better > >in a many > >HA settings. > > Our own requirements are quite modest and this has not been a problem so > far. However I'm sure others would benefit from a robust and high > performing implementation. > > I know little about the Netscape Directory SDK, but was under the > impression that the API it offers to programmers for access to directory > services is very different to JNDI. However, looking at the Mozilla site > today I noticed that an LDAP provider for JNDI is included in version 4.1 > of the SDK. Were you perhaps contemplating using JNDI with this Netscape > LDAP provider rather than the Netscape LDAP API itself? If so, does the > Netscape LDAP provider for JNDI have advantages over Sun's version (other > than being open source of course) and are there still active developers? > (My impression was that there has been little activity over the last year). > > My feeling initially is that if we can work around any disadvantages it > would be best to stay with the JNDI API to directory services but allow for > a choice of LDAP providers. > > >I would love to work with you on the proposal for this. As I have indicated I > >started a wish list of things to code in this realm module you hit many of the > >points of what I was looking at doing. I agree for many folks the JNDI > >implementation can suit much of their needs, I have just run across some > >folks that > >wanted better support for more diverse network environments. > > I'd be happy to cooperate on this. > > >Let's flesh this out and see what comes from it. > > > >Tony > > > > > >John Holman wrote: > > > > > At 04:28 04/01/02, Tony Dahbura wrote: > > > >I would like to see about proposing the development of an additional realm > > > >module for tomcat. I have begun some design on this and think it will > > > >meet the > > > >needs of many folks out there utilizing LDAP. I would like to propose a > > > >native > > > >LDAP realm module that allows utlization of ldap features that may or may > > > >not be > > > >possible through the JNDI layer. > > > > > > As far as I can see, writing a "native LDAP realm module" - if by that you > > > mean using the API provided by the Netscape directory SDK rather than Sun's > > > JNDI API - would make little difference to the functionality possible. > > > There may be performance benefits, though I have read conflicting reports > > > on that. > > > > > > >The items I am looking at designing into this module are: > > > >1-Connection pooling to support high performance access > > > >2-HA capabilities to support failover if a server goes away > > > >3-Authentication via the server rather than comparison of the passwords in > > > >digested forms (this option will also be supported) > > > >4-support for other realm group models (still checking into this). > > > >5-User location without DN identification (no need to be able to build the > > > >DN to > > > >find the user) > > > >6-SSL support for communications > > > > > > Some history ... > > > > > > The current JNDIRealm implementation in Tomcat 4 is based on code I > > > proposed back in April last year. I believe the existing implementation is > > > sufficiently flexible to cover most ways of representing group information > > > in the directory (item 4), and adding SSL support (item 6) should be > > > trivial. However item 3 (authentication by binding to the directory as the > > > user rather than by retrieving credentials and comparing them explicitly in > > > the realm) and feature 5 (essentially, finding the user's DN by searching > > > the directory on an arbitrary attribute) are not included. I think items 3 > > > and 5 are essential if the module is to be of much practical use. > > > > > > In fact my original proposal did include much of the missing functionality > > > (though not the performance and availability enhancements you mention). > > > Craig made several significant improvements to the code before committing > > > it, but also removed support for items 3 and 5. I subsequently proposed a > > > patch restoring item 3, and planned to propose a second patch restoring > > > item 5 if the first patch was accepted. Craig's response was that we should > > > first get agreement on top-level goals, and proposed a functional > > > specification for the JNDI Realm which is included in the Tomcat release > > > documentation. This spec includes two "login modes" which cover item 3, but > > > says little about the other items. > > > > > > As far as I know there has been no discussion of the spec since then, and > > > it still has proposed status. So perhaps the next step before enhancing the > > > existing module would be for the group to reach agreement about the > > > required features and produce a revised spec. I'm afraid I never got round > > > to proposing changes to the spec myself but now the subject has come up > > > again I will try to have a go at it. (I'll probably need to look at the > > > format of the source document, which is in some dialect of xml). > > > > > > However, I don't know what the position would be about a completely new > > module. > > > > > > Cheers, John. > > > > > > -- > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
