struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Webapp Security?
Date Thu, 03 Jul 2003 19:05:07 GMT

On Thu, 3 Jul 2003, David Erickson wrote:

> Date: Thu, 3 Jul 2003 12:37:56 -0600
> From: David Erickson <>
> Reply-To: Struts Users Mailing List <>
> To: Struts Users Mailing List <>
> Subject: Re: Webapp Security?
> Ok well lets suppose you want to protect 100% of your content, perhaps minus
> the login.jsp or what not page.

For container managed security, a "/*" pattern is how you'd specify this
-- the container knows that the login page should not be included in that
(although I suspect various Tomcat 3.x versions had problems with this).

>  We just spent a couple hours brainstorming
> how to protect our webapp.  We want flexibility above and beyond what
> container security provides, so we want to use our own mechanisms pulling
> permissions from a database etc.  So we we have had two veins of thought.
> 1) Creating some kind of struts action that handles all incoming requests,
> where the web.xml maps  /* to struts and it handles it, by using the
> wildcard extension to map everything minus actions to a certain struts
> action, that can perform authentication for that resource, if permissions
> match ship it on, otherwise forward to an error.
> 2) Create a servlet that runs within tomcat that takes all requests,
> performs authentication, then ships it to either struts for actions or
> wherever else for resources.
> We only want to use tomcat4, not apache or anything.. these seem to us to be
> the only ways to get a good flexible handle on what people request and see.
> #1 would be something we would rather use because it requires only one
> running servlet which would be struts, whereas #2 would need 2 servlets.

One of the keys to container managed security is that you need to be able
to express your authorization decisions (what can the user do) in terms of
roles.  A "role" can be as coarse-grained or fine-grained as you want, and
many users can be assigned the same role.  Generally, the set of roles
owned by a user is statically determined by the container at login time,
but that is not mandated by the spec -- it's perfectly legal for a
container to implement a role (for example) that is assigned if it is now
8am-5pm on a weedkay, but not other times, to allow access to a particular
resource only during working hours.

The second key to effective use of container managed security is that you
can express access control decisions to particular URLs (or URL patterns)
in terms of an AND test between roles.  If you cannot do this; perhaps
because there are factors besides roles innvolved in the decision, you
might want to think about rolling your own security -- in that scenario, a
filter is probably your best bet.

Within Tomcat itself, there are several avenues to customizing the
behavior of container managed security, but they are all Tomcat specific:

* You can define your own Valve (the internal-to-Tomcat equivalent
  to a Filter), and cause it to be run either before or after the
  Valve that actually implements container managed security.  Valves
  have read/write access to the request object, so they can do
  pretty much anything.

* You can use one of the Realm implementations (like JDBCRealm or
  JNDIRealm) that lets you look up the authentication and authorization
  information in an external resource -- and your app can provide
  mechanisms to dynamically create new users and roles.  The existing
  implementations select the set of valid roles at login time.

* You can write a custom Realm implementation (perhaps based on one
  of the existing ones) that does the role check dynamically on each
  request, so you can have role lists that change dynamically over time.

But, it's really not clear from your description what you are really
after.  It's also not clear why you think standard container managed
security is not enough.  That makes it hard to give any useful specific

If you go with "roll your own" security, though, I would definitely
recommend that you implement it as a Filter rather than trying to modify
Struts to do this for you.  Let Struts focus on managing the application
workflow for authorized users, and deal with security related decisions in
a completely separate piece of code.

> Thoughts, comments?  Any other ways to do this?
> -David


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message