tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: catalina realms
Date Tue, 30 May 2000 15:49:51 GMT
Remy Maucherat wrote:

> > It is.  The theory is that you should be able to use the Realm to
> authenticate a
> > user, even outside the scope of a particular request (for example, if you
> are
> > doing a "single sign on" implementation (prior to issuing requests to a
> > particular application protected by this signon), or you want to
> authenticate an
> > administrator coming in through a non-HTTP channel).
> >
> > That being said, there are some practical difficulties in implementing
> things
> > like DIGEST authentication, which needs access to the cleartext password.
> > Nobody has come up with a really elegant solution yet (other than adding
> > Realm.getPassword() and allowing it to return null if the realm doesn't
> have
> > access to a cleartext version of the password).  There are probably some
> > specific issues on SSL authentication that will only show up when someone
> tries
> > to implement it as well.
> >
> > I'm not necessarily opposed to passing a Request object, but we need to
> think
> > through the ramifications.
> Speaking of that, I have DIGEST mostly done, as well bug fixes to the
> HTTP/1.1 connector and handling of the HTTP/1.1 specific headers (still a
> WIP, but with that HTTP/1.1 is mostly done).
> However, I'm still looking for clients supporting DIGEST. Does anyone know
> of one ?
> I came up with the following solution :
> Add that function in the Realm interface :
> > public Principal authenticate(String username, String digest,
> > String nonce, String realm,
> > String md5a2);
> That function will check the submitted digest with the given request
> parameters. If they match, a Principal object is returned, just in line with
> the behavior of public Principal authenticate(String username, String
> credentials).
> A base realm class is also introduced, and provides an implementation for
> this new authenticate function. Abstract helper functions are used by this
> default implementation :
> protected abstract String getPassword(String username);
> protected abstract Principal getPrincipal(String username);
> This is the best I could come up with to avoid exposing Principal objects
> factories or credentials accessors.
> If you agree to these changes, I'll commit them later today or tomorrow.
> Additionally, after I do this commit, I suggest using the http connector
> instead of the test connector as the default connector, so that the new one
> can get some real world testing.

These changes sound good, including changing the default connector in server.xml
-- I would like to test the new one.  The "test" connector on Win98 exhibits
some wierd behavior when you close the socket -- the browser keeps waiting for
more data for several more seconds unless you press Stop.  (This might also be a
JDK problem).

> Remy


View raw message