tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@costin.dnt.ro>
Subject Re: authorization providers (was More on JAAS)
Date Tue, 18 Apr 2000 18:07:26 GMT
> > - How do you plan to integrate between web-server-based authentication
> > and tomcat ? ( static files are served by the web server ).
>
> Two different approaches are feasible:
> * A Realm implementation that directly reads the same files, or
> * A Realm implementation that knows it's running with a web server
>   connector and uses the proprietary webserver-Tomcat protocol to
>   ask the questions it needs.
>
> In other words, its exactly the same amount of new code you would add in a subclass
> of SecurityCheck to do the same thing.

First is not an option - most Apache realms are not text file based ( at least DBM,
or LDAP, NIS, etc).
Second - most adapters are not bidirectional ( at least the stable one is not ), and it
adds
one ( or several ) round-trips to the server. And more important - Apache does
_not_ provide an API for authentication !!!!!
( neither NES or IIS as far as I know ). You just _can't_ ask apache to verify a
user and pasword or tell you what are the roles.

You can just let the authentication module in apache do it's job - and in this case
you don't even need a SecurityCheck.
Of course, same would be possible with Realm ( set up tomcat to not use
Realm, and let apache do the auth ) - but if you declare an interface people
will expect it to work, and the contracts to be respected.

With SecurityCheck - the only contract is that during the request processing
we will verify the user. No promises or exposed APIs ( when none is available).


> > - How can you implement "trust only users from a certain IP domain ( a very valid
> > and common security restriction )"?
> >
>
> Even easier (and doesn't require a Realm) - a Valve that looks at the value returned
> by getRemoteAddr() or getRemoteHost() and applies the filters you've configured.  One
> thing Valves can do that RequestInterceptors cannot is to handle the request and
> return (in this case, the IP filter Valve would return
> HttpServletResponse.SC_FORBIDDEN), instead of passing the request on to the rest of
> the engine - in particular, no Valve or Container after this filter would even see
> requests from invalid IP domains.  You'd undoubtedly deploy this Valve earlier in the
> request processing pipeline than the security check, to avoid wasting the time to
> look up a user you're not going to accept anyway because of the IP address filtering.

First - it's not true that RequestInterceptors can't handle the request - it just have to

set the handler. And yes, that's a solution - but what happens with Realm ? The
authentication
is done in a Valve here ( which is similar with RequestInterceptor - at least at the same

level ), in the adapter in the previous case - where do you use Realm then ?

If integrated with apache/IIS/NES -> web does the authentication ( required because
static
files need the same auth ), no Realm

If JAAS is used -> JAAS is a more powerfull interface and I hope people will use the
"real" thing if available ( and the only limitation is the JDK version - long term we
can expect the standard to win ).

If complex authentication rules are in place ( i.e anything more than user/pass) -> you
need
the valve or request interceptor

Even for LDAP auth - people will probably use JNDI or another toolkit, why add another
layer between the request processing and the data source ? ( given that LDAP may allow
complex conditions - we are back to previous case )



> > 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 ?
> >
>
> As Stefano would say :-), the issue is "separation of concerns".  The fundamental
> design issue that Catalina changes vs. Tomcat 3.x (in respect to security) is a
> separation between the following concepts:

That's exactly what the interceptor does - except that it doesn't impose a specific
API for user lookup. Creating an authentication API is not easy - and ( as seen in
JAAS) may take more than 2 methods. If the issue is "separation of concerns" -
then we should be concerned about processing the request and let security
exeperts design authentication APIs. ( and maybe use what exists instead of
creating yet-another-interface)

> * How do you implement request.isUserInRole()?  (This was Mark's
>   comment that sparked the current discussion).  Currently, there's
>   no way for the request implementation to "get to" the underlying
>   realm you've loaded into the interceptor.  The proposed solution
>   is to add yet another method callback to the 9 or 10 already there
>   in RequestInterceptor.  Like most of the other ones, this is only
>   needed to get around the fact that the two concepts above are
>   combined instead of separated.

The reason you need that - is to deal with the fact that the world is not
under our control !
Yes, it would be nice to just add Realm and say that we support
authentication sources that implment Realm - but in real world
you need a bit more.

It also allow cooperation between multiple security providers -
like in PAM.



> * What happens when another authentication method is added in
>   some future version of the servlet API?  The current architecture
>   forces you to add it to SecurityCheck (plus side effects on at least
>   three other source modules, instead of being able to do everything
>   in one place).  With Catalina, you can do that all in a single class,
>   or define a separate Valve for each type of authentication that is
>   installed when you read web.xml to see what is necessary.  And,
>   you can mix and match any authentication method with any Realm
>   implementation -- they don't have a common subclass, so they
>   can be developed and deployed independently.

SecurityCheck is just an example implementation - and normal
OO methods can still be used ( extend, use, etc). It's just that we try
to impose the minimal set of contracts and rules - and allow more
flexibility.

Any decent implementation of SecurityCheck ( integrated with JAAS,
LDAP, etc) will probably use a number of classes - since this is the
first implementation I don't think we have enough information and
experience to require a specific model or structure.



> Finally, it's amusing to note that this doesn't really add a new kind of object :-).
> We already have a MemoryRealm object with similar characteristics -- it's just hidden
> inside SecurityCheck (as a private class) instead of being public where it is more
> useful.

Yes - the MemoryRealm is just _one_ way to deal with that, and it's not part
of core and hidden to not let people believe that's the best solution. In fact, it's
probably a solution only in simple cases.

Even SecurityCheck is just one possible implementation, that can be reused
or just used as a start - but it's far from an interface.


> > 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.
> >
>
> One particular thing that's missing is a way to implement isUserInRole() without
> adding another callback.

It seems Realm also requires a callback for isUserInRole() ( except that it's hidden
in the implementation ). In most cases it is not even needed, since the roles can
be set up on authentication.



> On a larger scale, and as we will discuss more, I'm sure, Tomcat is not a web server
> -- that problem has been solved quite nicely, thank you.  Instead, it is a container
> for web based applications, which do not necessarily have the same requirements for
> functionality (or even the same sweet spots for performance optimizations).

That's exactly my point - tomcat is not a web server, it's a container for  web-based
applications - it needs a web server to work ( even if it's the simple http/1.0 java
adapter we use ).


> Doing things in Tomcat "just because web servers do them that way" is not a
> sufficient argument, without understanding the costs imposed by that design.  (For
> example, have you counted the number of empty method calls the current Interceptor
> design causes to happen on every request?  They are fairly cheap, but they are
> definitely not free.)

That's why getMethods() exists. It's not implemented, but it allows just that.
See the FILTER_VERSION flags in IIS, SAF config in NES and the hooks in
apache - same model.

Regarding costs - I suppose using an unproven model ( just because it may look
better on paper) is more costly.


> > 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.
> >
>
> The *interface* to the component is being defined (that's what Realm is for) so you
> can plug in the implementation you want.  This interface defines only what Tomcat
> needs to satisfy its questions ("is this user authenticated?"  "is this user in this
> role?").  Realm does not impose any restrictions on *how* those questions are
> answered.

Same is true for interceptor - just at a different level, and without adding a new
interface.


> As mentioned above, you've already done exactly the same thing inside SecurityCheck
> -- it's just hidden, so it's not useful quite everywhere it needs to be.  I'm
> proposing that people be able to implement realms independent of messing with
> SecurityCheck.

And I'm proposing that people be able to implement realms in JAAS or any
public authentication interface that is out there. They can reuse the code in
SecurityCheck or create a new interceptor - if people are using IIS/NES/Apache
they can and should just use the _existing_ interceptor.

In fact - it's a non-problem for most production environments. I suppose any
real web site has already a security system in place, and they probably have
apache modules to use it. So in most cases you don't need anything on the
tomcat side.  SecurityCheck is usefull just for simple web servers that have
no authentication or standalone tomcat.

Costin


Mime
View raw message