tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Preston L. Bannister" <>
Subject RE: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Mon, 10 Jan 2000 04:09:20 GMT
From: Hans Bergsten []
> But the Servlet API need, IMHO, to be extended with mechanisms for response
> filtering (see below) and application controlled access control.
> Many web applications, e.g. "groupware" apps like OneList, need to use a
> security scheme where new groups and users can be added dynamically by the
> application itself. Today this can only be done using one of the models
> Craig described in another mail in this thread; none of them is very attractive
> to me. 

OK, you got my attention here :).

IMHO security is an area in need of improvement, though how much of this falls 
strictly within the scope Tomcat is perhaps a question.

Over the next couple of months I should have some time to stare at the problem,
and write implementations for Win32, Unix, OS/390 and JNDI.  

Unless of course someone else gets there first :).

I'll write the implementations in any case, whether they are for Jakarta or not.
Naturally I'd like the result to be usable for Jakarta :).

> I believe this requirement can be satisfied by adding a new attribute to
> the form-login-config element in web.xml, e.g.
>   <!ELEMENT form-login-config (form-login-page, form-error-page, auth-class?)>
> where auth-class is a class that implements an Authenticator interface, e.g.
>   public interface Authenticator {
>     boolean authenticate(String user, String password);
>     boolean isInRole(String user, String role);
>   }
> It can be implemented in Tomcat through the Interceptor mechanism, and through
> other mechanisms in other servlet containers. An implementation of Authenticator
> can provide other methods used by the application to manage the user and
> groups known by the Authenticator. This way the application can be developed
> the same way as with regular container provided authetication, while parts of
> the app can still update the security database.

So far I've used a Properties instance to pass in the username/password/whatever, 
and another Properties instance to get back various user properties (full name, 
start page, etc.).  You may not always be passing a username/password...

But I won't claim to have thought this though yet either :).

View raw message