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" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > > To: Struts Users Mailing List <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
