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.
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. 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]>
