You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by David Erickson <de...@cmcflex.com> on 2003/07/02 19:26:38 UTC
Webapp Security?
Just curious how others have gone about protecting the resouces within their
webapp.. in our personal setup we would like to control access to every
resource if possible, we have our own custom login page that sets session
variables, and pulls the data from the database.
We can authenticate people with code in each of the actions, but nothing is
preventing someone from directly going to a jpg or a jsp file or anything of
the like. What I thought about doing was subclassing the tomcat connectors,
the default, the jsp one, and the struts one and then authenticating each
request.. but that adds a lot of overhead. Anybody have any other good
ideas? We'd like to stick with just tomcat 4.1.24... no apache (no
.htaccess).. what is everyone else implementing?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jul 2003, David Erickson wrote:
> Date: Thu, 3 Jul 2003 13:44:41 -0600
> From: David Erickson <de...@cmcflex.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: Webapp Security?
>
> Yes this makes excellent sense. And this is basically along the lines of
> what I think we may do, but I am wondering if you could just filter the
> action itself using Filters before it even gets to struts, and if they dont
> have permission to perform that action then it never even makes it to
> struts?
>
Yep.
> Also another question that has been burning in my mind that I havn't been
> able to figure out, lets suppose we run a struts action it is successful so
> its actionmapping forward is to test.jsp. When it forwards to test.jsp does
> the tomcat server parse back through the web.xml to see what servlet is
> supposed get that test.jsp, or does it do something else??
>
Struts uses RequestDispatcher.forward() to deal with the ActionForward
instance that is returned. Translating the context-relative path into a
call to a particular servlet or JSP page does indeed go back through the
servlet mappings you've defined in web.xml, the same way that the original
request URL is mapped to a servlet or JSP page based on these mappings.
One thing to note about this, in the context of the discussion on
container managed security, is that security constraints are enforced ONLY
on the original request from a client, not on RequestDispatcher calls. If
the application uses RequestDispatcher, the container assumes that it
knows what it is doing.
> -David
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by "Jamie M. Guillemette" <Ja...@av-basesystems.com>.
You are refering to jspc ?
In this case when you make a request for test.jsp,
it is first checked that no mapping in the web.xml matches this url.. in
your case there now is.. the servlet equivilent.. hence
your servlet gets run. If the web.xml did not contain the entry then it
would check physically that the jsp file could be served.
JMG
>Also another question that has been burning in my mind that I havn't been
>able to figure out, lets suppose we run a struts action it is successful so
>its actionmapping forward is to test.jsp. When it forwards to test.jsp
does
>the tomcat server parse back through the web.xml to see what servlet is
>supposed get that test.jsp, or does it do something else??
>
>-David
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by David Erickson <de...@cmcflex.com>.
Yes this makes excellent sense. And this is basically along the lines of
what I think we may do, but I am wondering if you could just filter the
action itself using Filters before it even gets to struts, and if they dont
have permission to perform that action then it never even makes it to
struts?
Also another question that has been burning in my mind that I havn't been
able to figure out, lets suppose we run a struts action it is successful so
its actionmapping forward is to test.jsp. When it forwards to test.jsp does
the tomcat server parse back through the web.xml to see what servlet is
supposed get that test.jsp, or does it do something else??
-David
----- Original Message -----
From: "Jamie M. Guillemette" <Ja...@av-basesystems.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Thursday, July 03, 2003 1:43 PM
Subject: Re: Webapp Security?
> Hi David...
>
> Here is what we did.
>
> we did not use the roles framework for security ( logins ) instead we
> created our own as we needed a more robust rights framework ( our had to
be
> context sensity as per the application.. ie..if the data is true then
these
> are your current right .. if not they may be different )
>
>
>
> as all struts programers should do :) we have extended the Action using
our
> own SecuredActionBase object and then all of our actions extend it ...
>
> Each action has a right assigned to it. You must have the right to view
this
> page / module / section.. The right check is made when the action is first
> run ( by the SecuredActionBase object ) and then control is released to
the
> action that extended it.. so that the actual business logic can be run. If
> the security test failed we forward them back to the main screen ( same
one
> they get after logging in )
>
> Hope i made sense if not let me know.
>
> JMG
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by "Jamie M. Guillemette" <Ja...@av-basesystems.com>.
Hi David...
Here is what we did.
we did not use the roles framework for security ( logins ) instead we
created our own as we needed a more robust rights framework ( our had to be
context sensity as per the application.. ie..if the data is true then these
are your current right .. if not they may be different )
as all struts programers should do :) we have extended the Action using our
own SecuredActionBase object and then all of our actions extend it ...
Each action has a right assigned to it. You must have the right to view this
page / module / section.. The right check is made when the action is first
run ( by the SecuredActionBase object ) and then control is released to the
action that extended it.. so that the actual business logic can be run. If
the security test failed we forward them back to the main screen ( same one
they get after logging in )
Hope i made sense if not let me know.
JMG
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by David Erickson <de...@cmcflex.com>.
Basically just not wanting people to access resources they are not supposed
to. For example we may have certain spec sheets on products we want to show
to some people and not to others. Obviously the navigation logic for
someone with less permissions won't give them links to things they cannot
view with their permissions, however if they knew the exact url to the
resource nothing would stop them from viewing that without some kind of
security in place to check if they have permissions to view that resource.
-David
----- Original Message -----
From: "Jamie M. Guillemette" <Ja...@av-basesystems.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Thursday, July 03, 2003 12:52 PM
Subject: Re: Webapp Security?
> David,
>
> First let me apologize for i have not read all of the email relating to
your
> topic. However,
> my question is very specific. Are you trying to prevent people from
> tampering with your code... or just getting around your security to access
> pages they are
> not suppose to.
>
> In my own project we build serveral layers of security on top of the
struts
> model. It worked out pretty nicely so i would be happy to share what we
> did .. i just need to know what your goals are so i can tell you info that
> relates :)
>
> JMG
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by "Jamie M. Guillemette" <Ja...@av-basesystems.com>.
David,
First let me apologize for i have not read all of the email relating to your
topic. However,
my question is very specific. Are you trying to prevent people from
tampering with your code... or just getting around your security to access
pages they are
not suppose to.
In my own project we build serveral layers of security on top of the struts
model. It worked out pretty nicely so i would be happy to share what we
did .. i just need to know what your goals are so i can tell you info that
relates :)
JMG
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Rick Reumann <r...@reumann.net>.
And of course UserBean has a isInRole(role) method so if you need to
have fine control anywhere you have it. The servlet filter stuff is nice
because you can configure this part in an xml file... but I'm still
having that one issue that I just posted about.. (problem when user is
deep in an app and the session times out and after the user now is
brought back to the login page and submits the user is returned to where
he left off, which errors out bc some stuff is missing in the sesion
that your normally get to by going through the steps).
On Thu, 2003-07-03 at 15:00, Rick Reumann wrote:
> On Thu, 2003-07-03 at 14:37, David Erickson wrote:
>
> > Thoughts, comments? Any other ways to do this?
>
> I like to subclass the RequestProcessor and over-ride the process
> method:
>
>
> public void process(HttpServletRequest request, HttpServletResponse
> response)
> throws IOException, ServletException {
>
> Here I do a simple check to make sure that there is a "UserBean" in
> session scope. If it is not then the are forwarded to the login Page
> which submits to the LoginAction and everything gets setup like you
> mentioned. Seems clean and simple to me.
>
> Only small problem is if later on way down the road the RequestProcessor
> changes in Struts.
>
> The other thing I like is just make sure the only way you can get
> anywhere is through an Action mapping /do/* or .do whatever. Then I have
> all my actions extend a BaseAction (BaseDispatchAction actually). In
> there I overwrite the execute method which does the same as in the
> over-ridden class above.
>
> This later idea is probably better but you just have to remember to make
> sure all your actions extend a BaseAction.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Rick Reumann <r...@reumann.net>.
On Thu, 2003-07-03 at 14:37, David Erickson wrote:
> Thoughts, comments? Any other ways to do this?
I like to subclass the RequestProcessor and over-ride the process
method:
public void process(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException {
Here I do a simple check to make sure that there is a "UserBean" in
session scope. If it is not then the are forwarded to the login Page
which submits to the LoginAction and everything gets setup like you
mentioned. Seems clean and simple to me.
Only small problem is if later on way down the road the RequestProcessor
changes in Struts.
The other thing I like is just make sure the only way you can get
anywhere is through an Action mapping /do/* or .do whatever. Then I have
all my actions extend a BaseAction (BaseDispatchAction actually). In
there I overwrite the execute method which does the same as in the
over-ridden class above.
This later idea is probably better but you just have to remember to make
sure all your actions extend a BaseAction.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 7 Jul 2003, Rick Reumann wrote:
> Date: 07 Jul 2003 00:47:20 -0400
> From: Rick Reumann <r...@reumann.net>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: Webapp Security?
>
> On Thu, 2003-07-03 at 16:42, Craig R. McClanahan wrote:
> >
> >
> > Why are you trying to mess with the container's implementation of
> > authentication at all? Why not just write a Filter that does an
> > RD.forward() to some safe place if it sees that the session does not
> > contain the right stuff (because it was timed out and recreated)?
> > Remember, a filter is *not* required to call chain.doFilter() to pass the
> > request on -- it can forward wherever it wants and then return, and this
> > is portable to any Servlet 2.3 container.
> >
> > Filters are your friend :-).
>
>
> Well, here's the deal... Basically there are are too many things that
> rely on certain objects being in Session scope for this application so I
> don't want to have to test every type of action url. So what I did was
> write a Servlet Filter that also is called from the urr pattern /*
>
> the relevant filter method looks like :
>
> if ( httpRequest.getUserPrincipal() != null &&
> session.getAttribute("userBean") == null ) {
> RequestDispatcher rd = request.getRequestDispatcher(mainPage);
> rd.forward(request, response );
> }
> else {
> chain.doFilter(request, response);
> }
>
>
> The above seems to work fine- forcing the forward to the mainPage (which
> in my case is an index page that then forwards to an Action that sets up
> appropriate Session information).
>
> Throughout the course of the application there are other session objects
> (mainly some Lists for reporting that are put in Session scope) so
> rather than test for everything and have to figure out what page/action
> to bring the user to in oder to make things are set up correctly, I just
> want them all back some initial page.
>
> The part I don't like is every request now has to hit both the security
> filter and this other filter. Would it maybe be better to maybe just do
> this type of check in my base action execute method? (check for the
> userBean being null there and if null forward to the appropriate
> setUpAction?
>
I wouldn't be concerned -- combining things through composition (versus
putting everything in one big class) makes the individual pieces much
easier to understand and maintain.
Also, note that the Filter approach works even if your user tries to
request a JSP page directly, while embedding the logic in your Action
would not catch this.
> Thanks,
>
> --
> Rick
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Rick Reumann <r...@reumann.net>.
On Thu, 2003-07-03 at 16:42, Craig R. McClanahan wrote:
>
>
> Why are you trying to mess with the container's implementation of
> authentication at all? Why not just write a Filter that does an
> RD.forward() to some safe place if it sees that the session does not
> contain the right stuff (because it was timed out and recreated)?
> Remember, a filter is *not* required to call chain.doFilter() to pass the
> request on -- it can forward wherever it wants and then return, and this
> is portable to any Servlet 2.3 container.
>
> Filters are your friend :-).
Well, here's the deal... Basically there are are too many things that
rely on certain objects being in Session scope for this application so I
don't want to have to test every type of action url. So what I did was
write a Servlet Filter that also is called from the urr pattern /*
the relevant filter method looks like :
if ( httpRequest.getUserPrincipal() != null &&
session.getAttribute("userBean") == null ) {
RequestDispatcher rd = request.getRequestDispatcher(mainPage);
rd.forward(request, response );
}
else {
chain.doFilter(request, response);
}
The above seems to work fine- forcing the forward to the mainPage (which
in my case is an index page that then forwards to an Action that sets up
appropriate Session information).
Throughout the course of the application there are other session objects
(mainly some Lists for reporting that are put in Session scope) so
rather than test for everything and have to figure out what page/action
to bring the user to in oder to make things are set up correctly, I just
want them all back some initial page.
The part I don't like is every request now has to hit both the security
filter and this other filter. Would it maybe be better to maybe just do
this type of check in my base action execute method? (check for the
userBean being null there and if null forward to the appropriate
setUpAction?
Thanks,
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jul 2003, Rick Reumann wrote:
> Date: 03 Jul 2003 15:22:55 -0400
> From: Rick Reumann <r...@reumann.net>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: Webapp Security?
>
> On Thu, 2003-07-03 at 15:05, Craig R. McClanahan wrote:
>
> >
> > 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.
>
> Craig, is there a way I can force container managed security under
> Tomcat to always bring me to action X after login and not to the last
> url the user was at when their session timed out and they hit reload on
> a page? I'm having trouble because info is not in the session when the
> user is brought back tot he page they were last on before their session
> timed out. Is there a way to avoid this if I just use the standard
> Tomcat container based security?
>
Why are you trying to mess with the container's implementation of
authentication at all? Why not just write a Filter that does an
RD.forward() to some safe place if it sees that the session does not
contain the right stuff (because it was timed out and recreated)?
Remember, a filter is *not* required to call chain.doFilter() to pass the
request on -- it can forward wherever it wants and then return, and this
is portable to any Servlet 2.3 container.
Filters are your friend :-).
> Thanks
>
> --
> Rick
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Dolf Starreveld <do...@starreveld.com>.
At 15:46 -0400 7/3/03, Rick Reumann spoke thusly:
I suppose what I meant to convey, but failed to do is that I use CMS
(or a close cousing through SecurityFilter). The object that I am
checking for in the base class is a User object. I am not checking it
for security, but to deal with the logout/bring the user back
problem. If the object is not in session, I get the Principal from
the request and use it to locate the User BO and put it in session. I
then do not need to send the user back to a main page.
This should work with real CMS as well.
>On Thu, 2003-07-03 at 15:27, Dolf Starreveld wrote:
>
>> >
>> How about deriving all your actions from a base class that checks if
>> the requisite objects are in session, and if not, either puts them
>> there, or forwards/redirects to a page which will cause them to be
>> put there.
>> If you prefer, you can of course also do this in a
>>RequestProcessor subclass.
>>
>> I do the former and it works like a charm under any container (in my
>> case Jetty and SecurityFilter).
>
>he he that's exactly what I do do (see earlier post from a little while
>ago:). I just wanted to give Container managed security a try since it
>seems to be the rage these days:)
>
>--
>Rick
>
>my post similar to yours was:
>
>I like to subclass the RequestProcessor and over-ride the process
>method:
>
>
> public void process(HttpServletRequest request,
>HttpServletResponse
>response)
> throws IOException, ServletException {
>
>Here I do a simple check to make sure that there is a "UserBean" in
>session scope. If it is not then the are forwarded to the login Page
>which submits to the LoginAction and everything gets setup like you
>mentioned. Seems clean and simple to me.
>
>Only small problem is if later on way down the road the RequestProcessor
>changes in Struts.
>
>The other thing I like is just make sure the only way you can get
>anywhere is through an Action mapping /do/* or .do whatever. Then I have
>all my actions extend a BaseAction (BaseDispatchAction actually). In
>there I overwrite the execute method which does the same as in the
>over-ridden class above.
>
>This later idea is probably better but you just have to remember to make
>sure all your actions extend a BaseAction.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Rick Reumann <r...@reumann.net>.
On Thu, 2003-07-03 at 15:27, Dolf Starreveld wrote:
> >
> How about deriving all your actions from a base class that checks if
> the requisite objects are in session, and if not, either puts them
> there, or forwards/redirects to a page which will cause them to be
> put there.
> If you prefer, you can of course also do this in a RequestProcessor subclass.
>
> I do the former and it works like a charm under any container (in my
> case Jetty and SecurityFilter).
he he that's exactly what I do do (see earlier post from a little while
ago:). I just wanted to give Container managed security a try since it
seems to be the rage these days:)
--
Rick
my post similar to yours was:
I like to subclass the RequestProcessor and over-ride the process
method:
public void process(HttpServletRequest request,
HttpServletResponse
response)
throws IOException, ServletException {
Here I do a simple check to make sure that there is a "UserBean" in
session scope. If it is not then the are forwarded to the login Page
which submits to the LoginAction and everything gets setup like you
mentioned. Seems clean and simple to me.
Only small problem is if later on way down the road the RequestProcessor
changes in Struts.
The other thing I like is just make sure the only way you can get
anywhere is through an Action mapping /do/* or .do whatever. Then I have
all my actions extend a BaseAction (BaseDispatchAction actually). In
there I overwrite the execute method which does the same as in the
over-ridden class above.
This later idea is probably better but you just have to remember to make
sure all your actions extend a BaseAction.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Dolf Starreveld <do...@starreveld.com>.
At 15:22 -0400 7/3/03, Rick Reumann spoke thusly:
>On Thu, 2003-07-03 at 15:05, Craig R. McClanahan wrote:
>
>>
>> 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.
>
>Craig, is there a way I can force container managed security under
>Tomcat to always bring me to action X after login and not to the last
>url the user was at when their session timed out and they hit reload on
>a page? I'm having trouble because info is not in the session when the
>user is brought back tot he page they were last on before their session
>timed out. Is there a way to avoid this if I just use the standard
>Tomcat container based security?
>
How about deriving all your actions from a base class that checks if
the requisite objects are in session, and if not, either puts them
there, or forwards/redirects to a page which will cause them to be
put there.
If you prefer, you can of course also do this in a RequestProcessor subclass.
I do the former and it works like a charm under any container (in my
case Jetty and SecurityFilter).
--dolf
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Rick Reumann <r...@reumann.net>.
On Thu, 2003-07-03 at 15:05, Craig R. McClanahan wrote:
>
> 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.
Craig, is there a way I can force container managed security under
Tomcat to always bring me to action X after login and not to the last
url the user was at when their session timed out and they hit reload on
a page? I'm having trouble because info is not in the session when the
user is brought back tot he page they were last on before their session
timed out. Is there a way to avoid this if I just use the standard
Tomcat container based security?
Thanks
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by David Erickson <de...@cmcflex.com>.
Ya I am thinking that creating our own security with the use of filters is
the way to go. Filters is exactly what I was after but didn't know existed,
instead I was trying to extend all the containers that Tomcat uses for
resources, IE the JSP one, the one for everything else, and the struts
container, and then having authentication built into each of their request
methods.
What we are after is having databases that contain permission to perform
actions, permissions to see certain resources, and the capability to extend
that to other things, IE which menu elements they can see on navigation
pages etc. And we don't want to define groups that have selections of all
of those, we want each individual user to be able to have different
combinations of the above based on what permissions we want him to have.
Stereotyping groups is to limited for what we want to do. So I think we'll
probably use filters to accomplish this.. thoughts?
-David
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Thursday, July 03, 2003 1:05 PM
Subject: Re: Webapp Security?
>
>
> On Thu, 3 Jul 2003, David Erickson wrote:
>
> > Date: Thu, 3 Jul 2003 12:37:56 -0600
> > From: David Erickson <de...@cmcflex.com>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > 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: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jul 2003, David Erickson wrote:
> Date: Thu, 3 Jul 2003 12:37:56 -0600
> From: David Erickson <de...@cmcflex.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Erik Price <ep...@ptc.com>.
Rick Reumann wrote:
> On Thu, 2003-07-03 at 14:41, Erik Price wrote:
>
>
>>I am really confused as to why you don't want to use a Filter. It seems
>>that they were developed specifically for situations like the one you
>>describe
>
>
> Here's the problem I'm having with the securityFilter stuff that I'm
> implementing. Not sure if this what the spec requires, but when a user's
> session times out on some page and they hit reload I get brought back to
> the login page. That's all well and good, but when they submit it tries
> to return them to whatever URL they were on. This is creating problems
> because sometimes to get where the user was requires certain objects to
> be in the session which, right after login, they are not since the user
> has now skipped those actions and pages and is jumping to some point
> possibly deep into the application.
Hm. I am not familiar with the SecurityFilter project per se, but you
can always write your own implementation of javax.servlet.Filter and in
addition to performing your authorization tests, you can redirect or
dispatch-forward to a "safe" place in your web application. Better yet,
just modify the SecurityFilter that you are already using to do this,
since presumably you don't want to be troubled with re-coding all of the
authentication testing, etc.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Rick Reumann <r...@reumann.net>.
On Thu, 2003-07-03 at 14:41, Erik Price wrote:
> I am really confused as to why you don't want to use a Filter. It seems
> that they were developed specifically for situations like the one you
> describe
Here's the problem I'm having with the securityFilter stuff that I'm
implementing. Not sure if this what the spec requires, but when a user's
session times out on some page and they hit reload I get brought back to
the login page. That's all well and good, but when they submit it tries
to return them to whatever URL they were on. This is creating problems
because sometimes to get where the user was requires certain objects to
be in the session which, right after login, they are not since the user
has now skipped those actions and pages and is jumping to some point
possibly deep into the application.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Erik Price <ep...@ptc.com>.
David Erickson wrote:
> Ok well lets suppose you want to protect 100% of your content, perhaps minus
> the login.jsp or what not page. 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.
I am really confused as to why you don't want to use a Filter. It seems
that they were developed specifically for situations like the one you
describe.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by David Erickson <de...@cmcflex.com>.
Ok well lets suppose you want to protect 100% of your content, perhaps minus
the login.jsp or what not page. 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.
Thoughts, comments? Any other ways to do this?
-David
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Thursday, July 03, 2003 11:34 AM
Subject: Re: Webapp Security?
>
>
> On Thu, 3 Jul 2003, Adam Hardy wrote:
>
> > Date: Thu, 03 Jul 2003 13:47:20 +0200
> > From: Adam Hardy <ah...@cyberspaceroad.com>
> > Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> > To: Struts Users Mailing List <st...@jakarta.apache.org>
> > Subject: Re: Webapp Security?
> >
> > Adam Hardy wrote:
> > > Marc wrote:
> > >
> > >> To protect your JSP, put them in a subdir of WEB-INF. Actions are
> > >> still able to redirect to those JSPs but they are not direct
accessible.
> > >>
> > >> To protect your other files, just make a servlet and use path-mapping
> > >> like '/resources/*' to map all requests to this servlet.
> > >
> > >
> > >
> > > What kind of security breaches are JSPs susceptible to, once they
> > > protected by a security-constraint path mapping?
> >
> > what I mean is, are other files like HTML & style sheets & images
> > vulnerable?
>
> The reason people are concerned about putting JSP pages inside /WEB-INF is
> generally to avoid clients trying to access them directly (by typing a URL
> into the location bar); it is not really a security issue. In effect, the
> container provides an automatic security constraint that disallows ALL
> direct accesses from the client to anything under /WEB-INF.
>
> What you generally care about (from a security perspective) is ensuring
> that only authorized persons can perform dynamic actions on your web
> application. If you don't care who can do something, then don't protect
> it with a security constraint. The same goes for static content -- if the
> content is confidential to people that only have a particular role, then
> protect it with a security constraint that requires that role before
> allowing access. It doesn't matter whether the particular resource is
> implemented with JSP pages or ASP, or whether it's static or dynamic --
> the key question is "should person X be able to access it".
>
> It is *generally* simpler to use container managed security for things
> like this, because you can declare the constraints declaratively in your
> web.xml file, and not have to enforce it with functional logic inside your
> app. But there are also going to be cases where your needs go beyond what
> standard container managed security provides -- the way you make a choice
> should start from understanding what you're trying to protect and from
> whom, before deciding how to protect it.
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Ok is it just me?
Posted by Micael <ca...@harbornet.com>.
Ssssshhhh! Mark is sleeping.
At 01:33 PM 7/4/03 -0400, you wrote:
>Or did this discussion group just get very very very quiet.. ?
>( must be all those americans enjoying there day off :P )
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
LEGAL NOTICE
This electronic mail transmission and any accompanying documents contain
information belonging to the sender which may be confidential and legally
privileged. This information is intended only for the use of the
individual or entity to whom this electronic mail transmission was sent as
indicated above. If you are not the intended recipient, any disclosure,
copying, distribution, or action taken in reliance on the contents of the
information contained in this transmission is strictly prohibited. If you
have received this transmission in error, please delete the message. Thank
you
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Ok is it just me?
Posted by "Jamie M. Guillemette" <Ja...@av-basesystems.com>.
Or did this discussion group just get very very very quiet.. ?
( must be all those americans enjoying there day off :P )
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Cause its a virtual friday
Posted by "Jamie M. Guillemette" <Ja...@av-basesystems.com>.
-go to http://www.google.com
-- type: "weapons of mass destruction" (with the quotes)
-- hit the "I'm feeling lucky" button
be sure to read the error message closely
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 3 Jul 2003, Adam Hardy wrote:
> Date: Thu, 03 Jul 2003 13:47:20 +0200
> From: Adam Hardy <ah...@cyberspaceroad.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Re: Webapp Security?
>
> Adam Hardy wrote:
> > Marc wrote:
> >
> >> To protect your JSP, put them in a subdir of WEB-INF. Actions are
> >> still able to redirect to those JSPs but they are not direct accessible.
> >>
> >> To protect your other files, just make a servlet and use path-mapping
> >> like '/resources/*' to map all requests to this servlet.
> >
> >
> >
> > What kind of security breaches are JSPs susceptible to, once they
> > protected by a security-constraint path mapping?
>
> what I mean is, are other files like HTML & style sheets & images
> vulnerable?
The reason people are concerned about putting JSP pages inside /WEB-INF is
generally to avoid clients trying to access them directly (by typing a URL
into the location bar); it is not really a security issue. In effect, the
container provides an automatic security constraint that disallows ALL
direct accesses from the client to anything under /WEB-INF.
What you generally care about (from a security perspective) is ensuring
that only authorized persons can perform dynamic actions on your web
application. If you don't care who can do something, then don't protect
it with a security constraint. The same goes for static content -- if the
content is confidential to people that only have a particular role, then
protect it with a security constraint that requires that role before
allowing access. It doesn't matter whether the particular resource is
implemented with JSP pages or ASP, or whether it's static or dynamic --
the key question is "should person X be able to access it".
It is *generally* simpler to use container managed security for things
like this, because you can declare the constraints declaratively in your
web.xml file, and not have to enforce it with functional logic inside your
app. But there are also going to be cases where your needs go beyond what
standard container managed security provides -- the way you make a choice
should start from understanding what you're trying to protect and from
whom, before deciding how to protect it.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Adam Hardy wrote:
> Marc wrote:
>
>> To protect your JSP, put them in a subdir of WEB-INF. Actions are
>> still able to redirect to those JSPs but they are not direct accessible.
>>
>> To protect your other files, just make a servlet and use path-mapping
>> like '/resources/*' to map all requests to this servlet.
>
>
>
> What kind of security breaches are JSPs susceptible to, once they
> protected by a security-constraint path mapping?
what I mean is, are other files like HTML & style sheets & images
vulnerable?
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Marc wrote:
> To protect your JSP, put them in a subdir of WEB-INF. Actions are still
> able to redirect to those JSPs but they are not direct accessible.
>
> To protect your other files, just make a servlet and use path-mapping
> like '/resources/*' to map all requests to this servlet.
What kind of security breaches are JSPs susceptible to, once they
protected by a security-constraint path mapping?
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Marc <ru...@gmx.de>.
David Erickson wrote:
> Just curious how others have gone about protecting the resouces within their
> webapp.. in our personal setup we would like to control access to every
> resource if possible, we have our own custom login page that sets session
> variables, and pulls the data from the database.
>
To protect your JSP, put them in a subdir of WEB-INF. Actions are still
able to redirect to those JSPs but they are not direct accessible.
To protect your other files, just make a servlet and use path-mapping
like '/resources/*' to map all requests to this servlet.
Any resource request like 'resources/image.gif' is mapped to this
servlet, which can check user rights and decide to send back the
requested data or not. The resources itself can be in any directory on
the server, which can be accessed directly by the servlet. You may even
map above resource request to different directories for each user.
Hope this helps
Regards
Markus
> We can authenticate people with code in each of the actions, but nothing is
> preventing someone from directly going to a jpg or a jsp file or anything of
> the like. What I thought about doing was subclassing the tomcat connectors,
> the default, the jsp one, and the struts one and then authenticating each
> request.. but that adds a lot of overhead. Anybody have any other good
> ideas? We'd like to stick with just tomcat 4.1.24... no apache (no
> .htaccess).. what is everyone else implementing?
> -David
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "David Erickson" <de...@cmcflex.com>
To: "Struts Mailing List" <st...@jakarta.apache.org>
Sent: Wednesday, July 02, 2003 12:26 PM
Subject: Webapp Security?
> Just curious how others have gone about protecting the resouces within
their
> webapp.. in our personal setup we would like to control access to every
> resource if possible, we have our own custom login page that sets session
> variables, and pulls the data from the database.
>
> We can authenticate people with code in each of the actions, but nothing
is
> preventing someone from directly going to a jpg or a jsp file or anything
of
> the like. What I thought about doing was subclassing the tomcat
connectors,
> the default, the jsp one, and the struts one and then authenticating each
> request.. but that adds a lot of overhead. Anybody have any other good
> ideas? We'd like to stick with just tomcat 4.1.24... no apache (no
> .htaccess).. what is everyone else implementing?
Preventing someone from directly going to the JSP pages for your web
applications is right thing to do. I just posted a summary with
the subject MVC, Security, and Redirect:
1) No one has direct access to any JSP pages in the
web applications.
2) Anybody is able to invoke the generalized action
controllers where the security checking is performed.
You could use a dummy role nobody to protect all of your application
oriented resources with the security constraints. If your
user accounts are stored in database, like our implementation,
you could map your users' id, group, ref, whatever to the role names
specified on the action mappings. Giving uers dynamic privileges is
also implemented in our codes.
> -David
>
>
Jing
Netspread Carrier
http://www.netspread.com
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Webapp Security?
Posted by Erik Price <ep...@ptc.com>.
David Erickson wrote:
> Just curious how others have gone about protecting the resouces within their
> webapp.. in our personal setup we would like to control access to every
> resource if possible, we have our own custom login page that sets session
> variables, and pulls the data from the database.
>
> We can authenticate people with code in each of the actions, but nothing is
> preventing someone from directly going to a jpg or a jsp file or anything of
> the like. What I thought about doing was subclassing the tomcat connectors,
> the default, the jsp one, and the struts one and then authenticating each
> request.. but that adds a lot of overhead. Anybody have any other good
> ideas? We'd like to stick with just tomcat 4.1.24... no apache (no
> .htaccess).. what is everyone else implementing?
Container managed security might be the easiest way to add security
constraints to a broad category of resources quickly. However, it
sounds like you're not already using container managed security, so
maybe you have a reason for not using it. In which case, I would
refactor the authentication code out of your actions and into a Filter
(or several Filters), so that you can then apply the security
constraints to both Actions, JSPs, JPEGs, or other static resources.
All you have to do then is just map the Filter to the resources you want
to protect -- and the Filter code itself will probably look almost
exactly like the code you originally had in your Actions.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org