You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by John Gregg <jo...@techarch.com> on 2002/06/13 17:44:15 UTC
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.
thanks
john
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: front controller pattern and security
Posted by Martin Jacobson <ma...@libero.it>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: front controller pattern and security
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 13 Jun 2002, John Gregg wrote:
> Date: Thu, 13 Jun 2002 10:44:15 -0500
> From: John Gregg <jo...@techarch.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>,
> john.gregg@techarch.com
> To: tomcat-user@jakarta.apache.org
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>