tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@exoffice.com>
Subject Re: catalina realms
Date Tue, 30 May 2000 01:52:55 GMT
> 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.

Remy


Mime
View raw message