And of course, static role based security is only half the issue. Most of the time you want to be checking that the data actioned upon is in the right state for that action - I'm not just talk about the "who" can do "what" but to "whom" (data) and "when" (state). We use a inhouse solution for this problem at the mo alongside struts. Perhaps this is getting into struts-user land as opposed to tc-user but maybe Craig and others could comment?
Bye, Les > -----Original Message----- > From: Martin Jacobson [mailto:[EMAIL PROTECTED]] > Sent: 14 June 2002 09:00 > To: Tomcat Users List > Subject: Re: front controller pattern and security > > > John Gregg wrote: > > > Hi all. > > > > I've been thinking about how the j2ee front controller > pattern (used by > > Struts et al.) does/does not take advantage of url-based > authorization > > constraints in web.xml. I want to avoid having to check > roles in my own > > code as much as possible. At first I thought I could > declare a URL like > > /somewebapp/somerole/* to require the "somerole" role > before being allowed > > access to my controller servlet. Another URL would be > > /somewebapp/someotherrole/* but would map to the same > servlet. That servlet > > would then pick off the action at the end of the URL and execute it. > > However, while I can restrict access to the servlet, or > whatever other > > "physical" resource I'm trying to protect, what I really > want to protect is > > the action that's executed. Am I just stuck with > enumerating all possible > > actions in by web.xml (/somewebapp/somerole/someaction, > > /somewebapp/somerole/someotheraction, etc.)? Should I > instead make a filter > > that enforces this for me? I'm facing the same problem > with Apache SOAP's > > rpcrouter. > > > > > Surely, the way you describe, using servlet-mapping & auth-constraint > does exactly what you want? > In other words, you have one (controller) servlet declared, > and you use > servlet-mapping to declare all urls that invoke that servlet. In > auth-contstraint you declare the mapping between urls and user roles. > So, when a user invokes /app/manager/ac_details, the auth-constraint > would trigger an authorisation check to make sure the user was in the > indicated role. Then (if he's allowed), because the > servlet-mapping maps > this url to the controller servlet, the controller servlet is > invoked, > and, as you say, you can then determine what the action was > (ac_details) > by examining the url. This method does not restrict access to the > controller servlet directly, but does protect the functions > to be performed. > > Or have I misunderstood? > > Martin > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
