Re: blocking access using filter (fwd)

[Richard Troy <rt...@ScienceTools.com>]

Date: Wed, 17 Oct 2001 16:41:33 -0700 (PDT)
From: Craig R. McClanahan <cr...@apache.org>
Reply-To: tomcat-user@jakarta.apache.org
To: tomcat-user@jakarta.apache.org
Subject: Re: blocking access using filter



On Wed, 17 Oct 2001, Taavi Tiirik wrote:

> Date: Wed, 17 Oct 2001 22:47:53 +0200
> From: Taavi Tiirik <tt...@ibs.ee>
> Reply-To: tomcat-user@jakarta.apache.org
> To: tomcat-user@jakarta.apache.org
> Subject: blocking access using filter
>
> Hey,
>
> I need more sophisticated access control for certain
> documents than JDBCRealm provides. These documents
> reside in separate directory tree and they are
> served by standalone tomcat 4. I have mapped an
> 'access control filter' to listen to all requests to
> this directory. Filter should behave like this:
>
> 1. If user is not logged in or if the session has
> timed out then it should open login page and after
> successful login it should try to access the very
> same request (ie. the same document).
>
> / I am using getRemoteUser() to determine if user
> is logged in. /
>
> 2. Filter performs a database lookup and decides if
> given user can access this document.
>
> / This step is easy and I can live with extra
> overhead needed for database query. /
>
> 3. If user does not have rights to access this
> document then filter should send error 404 (no such
> document).
>
> / This can be achieved using:
>   response.sendError( HttpServletResponse.SC_NOT_FOUND ); /
>
> 4. Do nothing... ie. user will get this document.
>
> / 'do nothing' actually means calling next filter in
>   chain like this:
>   chain.doFilter( request, response ); /
>

That's a pretty impressive amount of learning-by-doing!

>
> I have figured out all steps but the very first one.
> What should I do in filter in order to make tomcat
> to use it's standard authentication mechanism
> (JDBCRealm, form based login in my case) so
> the user could log in and still get required document?
>

What you've got so far doesn't really correspond to JDBCRealm, which is
just a way to tell Tomcat how to look up users.

I don't quite see why you need to modify the standard form-based login
mechanisms, either.  Can't you just use the standard form based login for
triggering authentication?  This would be as simple as a security
constraint that looks like this:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>The Entire Webapp</web-resource-name>
      <url-pattern> /* </url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name> * </role-name>
    </auth-constraint>
  </security-constraint>

The "/*" URL pattern means that every single URL inside this webapp is
protected by the constraint.  The "*" in role names mean that it doesn't
matter what role(s) the user has -- every request requires an
authenticated user.  Therefore, by the time your filter is invoked,
getRemoteUser() will return the username you are looking for, and you can
impose any *additional* constraints that you need to.

Form based login already does the rest of what your step (1) includes - it
remembers the page that the user asks for (if it switches them to the
login screen), and automatically "replays" it once authentication is done.

If you really did want to modify the Tomcat authenticator, you would need
to turn this filter into an implementation of the
"org.apache.catalina.Valve" interface, which is conceptually pretty
similar to a Filter.  Valves (including the standard one used for
authentication) are invoked before the Filters (and the ultimate servlet)
belonging to your web application are invoked.

> Please, any help is appreciated. I will happily donate
> this filter back to the group if I get it working and
> if there is interest.
>
> thanks in advance,
> Taavi
>
>

Craig



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>