You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Tony Dahbura <to...@dahbura.com> on 2002/05/18 01:21:24 UTC

news

John:
I never heard anymore on the pooling stuff you and I were working on.  Has there
been any headway with Craig on this.  Sorry I have been traveling some lately and
may not be caught up on my emails.

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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>