tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [Catalina] Volunteer to build the JNDI realm
Date Thu, 01 Jun 2000 16:23:42 GMT wrote:

> Hey folks,
> I'd like to volunteer to build the JNDI realm on the Catalina plan.
> 1. I've implemented something similar for the project that I am presently
> working on (which is using Tomcat as its servlet engine) and would like to
> use that experience to develop this realm.
> 2. The work done by the Tomcat team is excellent, and I'd like to
> contribute something in aid of the project.
> 3. This will be my first contribution to an Open-Source project, and will
> be done on my own time, so I'm picking a smallish piece of work!

Welcome, James!  I've taken the liberty of adding your name to the list of
volunteers (proposals/catalina/STATUS.html).

> To kick off a discussion of the design, for those that are interested, here
> are the implementation options as I see them, I'm open to alternatives!
> 1. The JNDI realm will connect to the directory when it is started, using
> the 'manager' account.  As each request for authentication comes in, it
> will search for the user name in the directory to confirm that the user
> exists.  It will then attempt to connect to the directory AGAIN, using the
> credentials supplied along with the user name.  It is my experience that
> directory servers generally don't like to return the user password's to
> their clients, hence the need to connect again. (my experience was with
> Netscape Directory Server).

That was my experience as well -- the cleartext version of the user password
may not even be available, because it only stores the encrypted version.

> 2. As option #1, only the 2nd connection for authentication will not be
> required as the user's 'web-site password' (as opposed to the user's
> 'directory password') will be stored in some plaintext attribute in the
> user's directory entry.

IMHO this should be something the administrator can configure.  The username
used by a person for authenticating access to a web application may have
nothing to do with the "real" username checked by option #1, so I should be
able to set up access to an arbitrary attribute on an arbitrary entry to do the

The same principle should apply to group membership -- maybe you could provide
a mechanism to configure a search query that takes the username and desired
role as parameters?

> 3.  The JNDI realm will only connect to the directory when authenticating a
> user, and it will connect using the credentials presented by the user.

This is pretty similar to #1.  You might want to do a login at server startup
time just to make sure that the directory server is there.

> 4.  If the connection has been encrypted with SSL and a client certificate
> has been presented, then we could compare the certificate being presented
> with the certificate stored in the directory as part of the user's
> directory entry.
> Of these, I think #1 and #3 are the real alternatives.

I'm selfish -- can't I have all of them?  :-)

Seriously, I think that the variations you've described (counting #1 and #3 as
essentially the same thing) are all reasonable use cases.  If we agree with
that, you might consider doing them all in one fairly complex implementation
that supports configuration options to choose the desired behavior, or as a set
of simpler Realm implementations that perform only one of the scenarios.  The
latter seems easier to build and maintain to me.

> Anyway, let me know what you think.

One thing to keep in mind about server environments -- they tend to run for a
long time.  In cases where you use a persistent connection to an external
resource (the manager login in scenario 1, for example), you probably want to
build in some mechanism to "refresh" the connection if it starts having
problems, or on some periodic schedule, so that you don't have to restart the
servlet container just because of problems here.

The same principle would apply to a JDBC-based realm that opens a connection at
startup time.

> Regards,
> James W.

Craig McClanahan

View raw message