tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: authorization providers (was More on JAAS)
Date Tue, 18 Apr 2000 05:18:27 GMT
> This is one of the reasons that I defined a separate Realm object in the
> Catalina architecture (see directory "proposals/catalina" in the source CVS
> repository).  A Realm is a very thin API that provides only what the servlet
> container needs to satisfy its requirements -- implementations on top of JNDI,
> JAAS, or whatever are quite easy to create.

That's exactly what I said - but in reverse :-)

- How do you plan to integrate between web-server-based authentication
and tomcat ? ( static files are served by the web server ).
- How can you implement "trust only users from a certain IP domain ( a very valid
and common security restriction )"?

And most important question:

Why use an interface that doesn't provide you anything that is not already
available, but reduce the flexibility and add complexity ?

What is missing in the current model? It seems all web servers ( IIS, Nes, Apache
at least) are doing fine with the filter/SAF/module model.

The interceptor is not supposed to implement password-based authentication -
it is just a _bridge_ between tomcat and the real backend - that can be anything,
including Realm ( or JAAS, or JNDI ). With the addition that you can take
complex decisions based on the full request.
Reading from JAAS - it may be a smart card or an eye-scanning device -
hard to fit it into authenticate( String user, char credentials[])  :-)

> But of course - a different class needs to be used to authenticate using

> > SSL certificates for example.
> > And another type to just integrate with  the Apache auth ( if you
> > let apache do the authentication and authorization - you don't want
> > your static files authenticated from a different database, and it's
> > clear that static files served by apache is important to support)
> >
> The logic of performing BASIC or DIGEST of FORM based authentication is plenty
> complicated enough, without trying to mold in authentication lookups.  It is
> also *independent* of the way that you do the password authentication and role
> identification.  That really needs to be its own component.

Yes - the interceptor is not supposed to implement authentication lookups, but to
_use_ a component. With the difference that the authentication component is not
imposed by tomcat, but it's anything you want, with any interface. It needs to be
in its own component - but the component is not under our control, we should use
existing systems where possible.


View raw message