RE: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

["Preston L. Bannister" <pr...@home.com>]

From: Hans Bergsten [mailto:hans@gefionsoftware.com]
[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.

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

Re: [LONG TERM PLAN] Proposed Architecture for Tomcat.Next Servlet Container

[Hans Bergsten <ha...@gefionsoftware.com>]

"Preston L. Bannister" wrote:
> 
> From: Hans Bergsten [mailto:hans@gefionsoftware.com]
> [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
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com