tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <>
Subject Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container
Date Mon, 10 Jan 2000 04:50:58 GMT
"Preston L. Bannister" wrote:
> From: Hans Bergsten []
> [snip]
> > 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.

Tomcat needs an implementation of the security that's already in defined in
Servlet 2.2, and Craig has already started in this area.

But I believe the security area needs to be extended in the Servlet API as
well, and that's what I hinted at above. But as I said, the servlet expert
group is a better place for this discussion.

> 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 :).

Cool, let us know how it goes. 

> > 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 :).

Neither have I, so the interface example above is just that; an example. But the 
general idea that an application can plug in its own Authenticator has value, IMHO.
Again, this discussion belongs in the servlet experts group.

Hans Bergsten
Gefion Software

View raw message