struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Dollin <Ed...@BLUE-MOOSE.NET>
Subject RE: Webapp Security?
Date Fri, 04 Jul 2003 14:43:04 GMT
If you do go with filters and there is one other issue to consider.  If you
are using a combination web-server and container then filters are straight
forward.  If you are using your container as a web-server you have to
structure your map to allow public area files (gif's, etc.) to pass through
the filter.

Edgar

> -----Original Message-----
> From: David Erickson [mailto:derickson@cmcflex.com] 
> Sent: Thursday, July 03, 2003 2:11 PM
> To: 'Struts Users Mailing List'
> Subject: Re: Webapp Security?
> 
> 
> Ya I am thinking that creating our own security with the use 
> of filters is the way to go.  Filters is exactly what I was 
> after but didn't know existed, instead I was trying to extend 
> all the containers that Tomcat uses for resources, IE the JSP 
> one, the one for everything else, and the struts container, 
> and then having authentication built into each of their 
> request methods.
> 
> What we are after is having databases that contain permission 
> to perform actions, permissions to see certain resources, and 
> the capability to extend that to other things, IE which menu 
> elements they can see on navigation pages etc.  And we don't 
> want to define groups that have selections of all of those, 
> we want each individual user to be able to have different 
> combinations of the above based on what permissions we want 
> him to have. Stereotyping groups is to limited for what we 
> want to do.  So I think we'll probably use filters to 
> accomplish this.. thoughts? -David
> 
> ----- Original Message ----- 
> From: "Craig R. McClanahan" <craigmcc@apache.org>
> To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> Sent: Thursday, July 03, 2003 1:05 PM
> Subject: Re: Webapp Security?
> 
> 
> >
> >
> > On Thu, 3 Jul 2003, David Erickson wrote:
> >
> > > Date: Thu, 3 Jul 2003 12:37:56 -0600
> > > From: David Erickson <derickson@cmcflex.com>
> > > Reply-To: Struts Users Mailing List 
> <struts-user@jakarta.apache.org>
> > > To: Struts Users Mailing List <struts-user@jakarta.apache.org>
> > > 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 advice.
> >
> > 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
> >
> > Craig
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message