You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jerome Jacobsen <je...@gentootech.com> on 2001/08/15 17:16:31 UTC
Does the servlet security model work with the J2EE Blueprint MVC?
Hello,
The Java Servlet Specification (Version 2.3, Draft 2) under SRV.12.2 states:
"The security model applies to the static content part of the web
application and to servlets within the application that are requested by the
client. The security model does not apply when a servlet uses the
RequestDispatcher to invoke a static resource or servlet using a forward()
or an include()."
Does this mean that using the MVC architecture with a Web controller as
described in the J2EE Blueprints precludes the use of this security model?
-Jerome
RE: Does the servlet security model work with the J2EE Blueprint
MVC?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 15 Aug 2001, Jerome Jacobsen wrote:
> What I meant is the declarative part of the security model. My app has a
> single Front Controller JSP. See below.
>
> <%@ page contentType="text/html;charset=WINDOWS-1252"%>
> <jsp:useBean id="ctrl" class=
> "com.gentootech.eip.webclient.controller.EipController"
> scope="application">
> <% ctrl.init(config, application); %>
> </jsp:useBean>
>
> <jsp:forward page= "<%= ctrl.service(session, request, response) %>"/>
>
> Can I *declaratively* control access to the other JSPs by specifying
> <security-role> and <security-constraint> elements in the deployment
> descriptor?
>
Yes, but only if your users are accessing the JSP pages directly.
If you're using the MVC architecture in the recommended fashion, all
requests should flow through the controller, *not* go directly to the
pages. So, the question is how does the user submit requests to your
controller?
In Struts (disclaimer - I'm the primary author, so I'm more familiar with
it and undoubtedly biased :-) the usual pattern is to use extension
mapping to map requests to the controller. A common pattern is to is to
use a "*.do" mapping (implying "go do something"). So, a typical URL
would be something like:
http://www.mycompany.com/myapp/submitPurchaseOrder.do
Now, if I want to manage who can submit purchase orders, it is *this* URL
that I care about protecting. If the user is allowed to submit purchase
orders, they should be allowed to view the submit confirmation screen that
follows (i.e. where your front controller forwards to after completing the
transaction), right? Thus, it doesn't need any extra protection.
To avoid users inadvertently or maliciously trying to access JSP pages
directly, you can place them in /WEB-INF as I described earlier.
> Thanks,
>
> -Jerome
>
Craig
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Wednesday, August 15, 2001 12:40 PM
> To: Tomcat User's Group; jerome.jacobsen@gentootech.com
> Subject: Re: Does the servlet security model work with the J2EE
> Blueprint MVC?
>
>
>
>
> On Wed, 15 Aug 2001, Jerome Jacobsen wrote:
>
> > Hello,
> >
> > The Java Servlet Specification (Version 2.3, Draft 2) under SRV.12.2
> states:
> >
> > "The security model applies to the static content part of the web
> > application and to servlets within the application that are requested by
> the
> > client. The security model does not apply when a servlet uses the
> > RequestDispatcher to invoke a static resource or servlet using a forward()
> > or an include()."
> >
>
> In other words, the security constraints are only matched on the initial
> request URI, not on paths passed to getRequestDispatcher().
>
> > Does this mean that using the MVC architecture with a Web controller as
> > described in the J2EE Blueprints precludes the use of this security model?
> >
>
> Not at all. You've got at least a couple of approaches to consider:
>
> * If your MVC architecture uses different URIs for different logical
> transactions (i.e. you are using either path mapping or extension
> mapping to map to the controller component) you can protect those
> URIs with appropriate security constraints.
>
> * Your controller component can (in addition to or instead of the
> restrictions based on security constraints) apply additional role-based
> checking -- perhaps defined in the configuration settings for the
> controller -- by calling request.isUserInRole() to check whether the
> user is authorized for one or more roles.
>
> * Roles can also be used in the view layer to change the presentation
> (for example, a manager might have more menu options to choose from
> than a regular user).
>
> In an MVC-architected web app, your primary concern is whether the user
> can perform the transaction that they requested. If they can, you
> naturally want them to see the results of performing that transaction, so
> there is no need to protect the RequestDispatcher.forward() used by the
> controller to forward control to the ultimate view component.
>
> But what if you have users that try to navigate to your JSP pages directly
> (and perhaps bookmark them). You can take advantage of a related
> specification requirement, and put those JSP pages inside the /WEB-INF
> directory. This works because the container will refuse to serve anything
> under /WEB-INF directly to the user, but RequestDispatcher.forward() can
> still be used to display them.
>
> > -Jerome
>
> Craig McClanahan
>
>
>
>
>
RE: Does the servlet security model work with the J2EE Blueprint MVC?
Posted by Jerome Jacobsen <je...@gentootech.com>.
What I meant is the declarative part of the security model. My app has a
single Front Controller JSP. See below.
<%@ page contentType="text/html;charset=WINDOWS-1252"%>
<jsp:useBean id="ctrl" class=
"com.gentootech.eip.webclient.controller.EipController"
scope="application">
<% ctrl.init(config, application); %>
</jsp:useBean>
<jsp:forward page= "<%= ctrl.service(session, request, response) %>"/>
Can I *declaratively* control access to the other JSPs by specifying
<security-role> and <security-constraint> elements in the deployment
descriptor?
Thanks,
-Jerome
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Wednesday, August 15, 2001 12:40 PM
To: Tomcat User's Group; jerome.jacobsen@gentootech.com
Subject: Re: Does the servlet security model work with the J2EE
Blueprint MVC?
On Wed, 15 Aug 2001, Jerome Jacobsen wrote:
> Hello,
>
> The Java Servlet Specification (Version 2.3, Draft 2) under SRV.12.2
states:
>
> "The security model applies to the static content part of the web
> application and to servlets within the application that are requested by
the
> client. The security model does not apply when a servlet uses the
> RequestDispatcher to invoke a static resource or servlet using a forward()
> or an include()."
>
In other words, the security constraints are only matched on the initial
request URI, not on paths passed to getRequestDispatcher().
> Does this mean that using the MVC architecture with a Web controller as
> described in the J2EE Blueprints precludes the use of this security model?
>
Not at all. You've got at least a couple of approaches to consider:
* If your MVC architecture uses different URIs for different logical
transactions (i.e. you are using either path mapping or extension
mapping to map to the controller component) you can protect those
URIs with appropriate security constraints.
* Your controller component can (in addition to or instead of the
restrictions based on security constraints) apply additional role-based
checking -- perhaps defined in the configuration settings for the
controller -- by calling request.isUserInRole() to check whether the
user is authorized for one or more roles.
* Roles can also be used in the view layer to change the presentation
(for example, a manager might have more menu options to choose from
than a regular user).
In an MVC-architected web app, your primary concern is whether the user
can perform the transaction that they requested. If they can, you
naturally want them to see the results of performing that transaction, so
there is no need to protect the RequestDispatcher.forward() used by the
controller to forward control to the ultimate view component.
But what if you have users that try to navigate to your JSP pages directly
(and perhaps bookmark them). You can take advantage of a related
specification requirement, and put those JSP pages inside the /WEB-INF
directory. This works because the container will refuse to serve anything
under /WEB-INF directly to the user, but RequestDispatcher.forward() can
still be used to display them.
> -Jerome
Craig McClanahan
Re: Does the servlet security model work with the J2EE Blueprint
MVC?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 15 Aug 2001, Jerome Jacobsen wrote:
> Hello,
>
> The Java Servlet Specification (Version 2.3, Draft 2) under SRV.12.2 states:
>
> "The security model applies to the static content part of the web
> application and to servlets within the application that are requested by the
> client. The security model does not apply when a servlet uses the
> RequestDispatcher to invoke a static resource or servlet using a forward()
> or an include()."
>
In other words, the security constraints are only matched on the initial
request URI, not on paths passed to getRequestDispatcher().
> Does this mean that using the MVC architecture with a Web controller as
> described in the J2EE Blueprints precludes the use of this security model?
>
Not at all. You've got at least a couple of approaches to consider:
* If your MVC architecture uses different URIs for different logical
transactions (i.e. you are using either path mapping or extension
mapping to map to the controller component) you can protect those
URIs with appropriate security constraints.
* Your controller component can (in addition to or instead of the
restrictions based on security constraints) apply additional role-based
checking -- perhaps defined in the configuration settings for the
controller -- by calling request.isUserInRole() to check whether the
user is authorized for one or more roles.
* Roles can also be used in the view layer to change the presentation
(for example, a manager might have more menu options to choose from
than a regular user).
In an MVC-architected web app, your primary concern is whether the user
can perform the transaction that they requested. If they can, you
naturally want them to see the results of performing that transaction, so
there is no need to protect the RequestDispatcher.forward() used by the
controller to forward control to the ultimate view component.
But what if you have users that try to navigate to your JSP pages directly
(and perhaps bookmark them). You can take advantage of a related
specification requirement, and put those JSP pages inside the /WEB-INF
directory. This works because the container will refuse to serve anything
under /WEB-INF directly to the user, but RequestDispatcher.forward() can
still be used to display them.
> -Jerome
Craig McClanahan