RE: front controller pattern and security
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]
RE: front controller pattern and security
On Sat, 15 Jun 2002, Les Hughes wrote: Date: Sat, 15 Jun 2002 08:32:53 +0100 From: Les Hughes [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Subject: RE: front controller pattern and security 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? Off the top of my head, I don't know of any generic frameworks for this sort of security management -- the details sound like they would always be pretty application specific. Bye, Les Craig -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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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]
Re: front controller pattern and security
On Thu, 13 Jun 2002, John Gregg wrote: Date: Thu, 13 Jun 2002 10:44:15 -0500 From: John Gregg [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: front controller pattern and security 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. A Filter would be a good solution if you are running on a Servlet 2.3 based platform (like Tomcat 4). Another approach is to see if your controller framework can help you out -- for example, Struts 1.1 lets you define the roles that are allowed to access a particular Action with the roles attribute on your action element. The simplest way to use this is to create a security constraint against URL pattern *.do that just forces the login, and then use the role restrictions on the actions to define which actions can be executed by which logged-in user. thanks john Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
