tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: catalina realms
Date Tue, 30 May 2000 00:51:08 GMT
Paul Lamb wrote:

> I've been moving a test site over to catalina today and need some
> elightenment. I noticed that authenticate() isn't passed the request object.
> Is this deliberate?
>

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.

>
> A couple of requirements are driving this question are because of the site
> I'm working on:
>
> 1. The remoteAddr value is used in the authentication. It's an extranet site
> that limits certain users to specific ip addresses.
>

Checking the IP addresses themselves isn't too tough -- just define new Valve
that performs the appropriate filtering against a list that is either configured
at startup time or via dynamic lookups to some sort of database or directory
server.

For per-IP username restrictions, a couple of different approaches might be
useful:

* A special Valve (perhaps extending an existing one) that has access to
multiple
  Realms -- one per valid IP address -- and uses the correct Realm for its
  authentication.

* A customized version of an existing security Valve that concatenates the
  IP address with the username, and uses that to do its authentication with
  the (single) connected Realm.

>
> 2. The client requires that the authentication success/failure logging
> includes both the remote ip address, the user agent, and ssl parameters.
> Again, this may be a little more intense than usual, but it's been really
> helpful in trying to help debug problems.
>

A logging Valve has access to all of this stuff, as long as it is earlier in the
pipeline than the authentication valve.  For example, the AccessLogValve
implementation in the default Catalina setup logs similar stuff (although not
SSL-related things).

One interesting issue to think about:  how do you tell the difference between
the 401 that is sent back to challenge a user for their credentials in the first
place, and the 401 that says they submitted incorrect credentials?  Sometimes
the statelessness of HTTP can be a pain.

>
> 3. You can't stick any objects in the session. You have to resort to
> creating a custom pricipal object and sticking them in there.

There might not be a session because there will not be a request in the use
cases described above.

>
> 4. Down the road if you do forms based authentication, it can be useful to
> stick an exception or such in the session so that you can display a message
> on the error form, say if someones subscription has expired.

This isn't going to be portable to other servlet containers, but I guess none of
the rest of this is either.

> Comments would be greatly appreciated.
>
> Paul Lamb
>

Craig McClanahan

PS:  Paul, you should subscribe to TOMCAT-DEV if you want to post there --
otherwise, your messages go to the moderator (me) and don't show up when I'm on
a long holiday weekend.




Mime
View raw message