Ok well lets suppose you want to protect 100% of your content, perhaps minus the login.jsp or what not page. 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. Thoughts, comments? Any other ways to do this? -David ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, July 03, 2003 11:34 AM Subject: Re: Webapp Security? > > > On Thu, 3 Jul 2003, Adam Hardy wrote: > > > Date: Thu, 03 Jul 2003 13:47:20 +0200 > > From: Adam Hardy <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > Subject: Re: Webapp Security? > > > > Adam Hardy wrote: > > > Marc wrote: > > > > > >> To protect your JSP, put them in a subdir of WEB-INF. Actions are > > >> still able to redirect to those JSPs but they are not direct accessible. > > >> > > >> To protect your other files, just make a servlet and use path-mapping > > >> like '/resources/*' to map all requests to this servlet. > > > > > > > > > > > > What kind of security breaches are JSPs susceptible to, once they > > > protected by a security-constraint path mapping? > > > > what I mean is, are other files like HTML & style sheets & images > > vulnerable? > > The reason people are concerned about putting JSP pages inside /WEB-INF is > generally to avoid clients trying to access them directly (by typing a URL > into the location bar); it is not really a security issue. In effect, the > container provides an automatic security constraint that disallows ALL > direct accesses from the client to anything under /WEB-INF. > > What you generally care about (from a security perspective) is ensuring > that only authorized persons can perform dynamic actions on your web > application. If you don't care who can do something, then don't protect > it with a security constraint. The same goes for static content -- if the > content is confidential to people that only have a particular role, then > protect it with a security constraint that requires that role before > allowing access. It doesn't matter whether the particular resource is > implemented with JSP pages or ASP, or whether it's static or dynamic -- > the key question is "should person X be able to access it". > > It is *generally* simpler to use container managed security for things > like this, because you can declare the constraints declaratively in your > web.xml file, and not have to enforce it with functional logic inside your > app. But there are also going to be cases where your needs go beyond what > standard container managed security provides -- the way you make a choice > should start from understanding what you're trying to protect and from > whom, before deciding how to protect it. > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
