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]
