John: It was all I could do to get the code posted!! I need to put the source code up as well-will get to it this week. I think it covers the features of your original proposal. How should we work on getting both of them admitted and beefing up the realm services. I am not an expert on working on projects like this-more of a developer.
I would like to take a stab at adding the functionality to the JNDIRealm module as well. I have always believed if users have multiple choices for things they will pick the one that works for them in their environment. Should I just start working on it? Do you want to work on it together? Let me know how we should proceed, Tony John Holman wrote: > Tony > > I had a look at the documentation for your LDAPRealm and apart from the HA > features it looks very similar to my original JNDIRealm proposal both in > features and configuration options. I couldn't see any source code on your > site though. > > I sent a revised functional specification to the tomcat-dev list a few > weeks ago elaborating on what I think are the most important features > (mostly authentication via simple bind and searching for the user's entry > when necessary) but got no response. I'd like to see those features in > JNDIRealm one way or the other but don't know how to make progress with > getting it accepted. > > John. > > At 03:52 26/01/02, you wrote: > >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]> > > -- > 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]>
