Re: Webapp Security?
On Sun, 7 Jul 2003, Rick Reumann wrote:
Date: 07 Jul 2003 00:47:20 -0400
From: Rick Reumann [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Webapp Security?
Look at the http://www.securityfilter.org project on sourceforge.
It provides a portable implementation that is similar to container security
but can be regarded as an improvment in some cases. request.isUserInRole
will work and also struts role checking.
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
Sent: 07 July, 2003 18:21
To: Struts Users Mailing List
Subject: Re: Webapp Security?
On Sun, 7 Jul 2003, Rick Reumann wrote:
Date: 07 Jul 2003 00:47:20 -0400
From: Rick Reumann [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
For information about the Standard Bank group visit our web site
www.standardbank.co.za
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relating to the official business of
Standard Bank Group Limited is proprietary to the group.
It is confidential, legally privileged and protected by law.
Standard Bank does not own and endorse any other content. Views and opinions are those
of the sender unless clearly stated as being that of the group.
The person addressed in the e-mail is the sole authorised recipient. Please notify the
sender immediately if it has unintentionally reached you and do not read,
disclose or use the content in any way.
Standard Bank can not assure that the integrity of this communication has been
maintained nor that it is free of errors, virus, interception or interference.
___
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?
Thanks,
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Webapp Security?
If you do go with filters and there is one other issue to consider. If you are using a combination web-server and container then filters are straight forward. If you are using your container as a web-server you have to structure your map to allow public area files (gif's, etc.) to pass through the filter. Edgar -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 2:11 PM To: 'Struts Users Mailing List' Subject: Re: Webapp Security? 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 [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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
Re: Webapp Security?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Webapp Security?
The who sees what problem is one I faced some time ago - and whilst I would have liked to use CMA / Filters, it simply was not a good fit for the application - each user had to have a range of different permissions based on one/more customer codes, one/more product codes and user role admin/company/customer/supplier - all of which had to be configurable for the individual user. I ended up writing my own application security manager - when the user logs in, his permissions are loaded from DB and then checked before any action is performed - with appropriate errors if a violation is detected. db -Original Message- From: Raible, Matt [mailto:[EMAIL PROTECTED] Sent: 02 July 2003 19:13 To: 'Struts Users Mailing List' Subject: RE: Webapp Security? If you want to give user's dynamic permissions at runtime, you could add a filter on top of container managed authentication (CMA). CMA is nice b/c you can use any authenticate with LDAP, a database (my example uses MySQL), or a flat file - or even an NT Domain. You'll probably have to setup some sort of system that defines who can see what - so you'll eventually (probably) end up implementing some sort of roles/groups - unless you're planning on checking for individual usernames or some such attribute before allowing access. Tomcat's security constraint stuff is the same thing as CMA. HTH, Matt -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:54 AM To: Struts Users Mailing List Subject: Re: Webapp Security? Is it based on using security restraints and having all your users set into groups in the tomcat-users.xml file? If so our problem is we don't want to have users based into groups but want to give permissions to users individually to many different things.. and we want to store our users in a database rather than tomcat's xml file.. if I am mistaken on how this works please correct me =) (I havn't actually looked at it, I've just looked at tomcat's security restraint stuff before) -David - Original Message - From: Raible, Matt [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:47 AM Subject: RE: Webapp Security? How about using container managed security with tomcat's realms? It works great for me. Here's an example app if you're interested: http://tinyurl.com/fuvq HTH, Matt -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:27 AM To: Struts Mailing List 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? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
On 02/07/2003 18:53 David Erickson wrote: Is it based on using security restraints and having all your users set into groups in the tomcat-users.xml file? If so our problem is we don't want to have users based into groups but want to give permissions to users individually to many different things.. and we want to store our users in a database rather than tomcat's xml file.. if I am mistaken on how this works please correct me =) (I havn't actually looked at it, I've just looked at tomcat's security restraint stuff before) Just set up a JDBC realm for your context and use roles. A role can be as fine or coarse grained as you like. Then just write an admin app which allows you assign roles to users. It's easy. -- Paul Thomas +--+-+ | Thomas Micro Systems Limited | Software Solutions for the Smaller Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +--+-+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
David how did you intercept incoming http requests for items so you could check to see if that was permisiable for the logged on user? I have thought about subclassing the tomcat connectors and putting in checks there before it serves the request, but that could become a lot of overhead rather quickly if you have very many things loading on a webpage. -David - Original Message - From: David Bolsover [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, July 03, 2003 3:56 AM Subject: RE: Webapp Security? The who sees what problem is one I faced some time ago - and whilst I would have liked to use CMA / Filters, it simply was not a good fit for the application - each user had to have a range of different permissions based on one/more customer codes, one/more product codes and user role admin/company/customer/supplier - all of which had to be configurable for the individual user. I ended up writing my own application security manager - when the user logs in, his permissions are loaded from DB and then checked before any action is performed - with appropriate errors if a violation is detected. db -Original Message- From: Raible, Matt [mailto:[EMAIL PROTECTED] Sent: 02 July 2003 19:13 To: 'Struts Users Mailing List' Subject: RE: Webapp Security? If you want to give user's dynamic permissions at runtime, you could add a filter on top of container managed authentication (CMA). CMA is nice b/c you can use any authenticate with LDAP, a database (my example uses MySQL), or a flat file - or even an NT Domain. You'll probably have to setup some sort of system that defines who can see what - so you'll eventually (probably) end up implementing some sort of roles/groups - unless you're planning on checking for individual usernames or some such attribute before allowing access. Tomcat's security constraint stuff is the same thing as CMA. HTH, Matt -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:54 AM To: Struts Users Mailing List Subject: Re: Webapp Security? Is it based on using security restraints and having all your users set into groups in the tomcat-users.xml file? If so our problem is we don't want to have users based into groups but want to give permissions to users individually to many different things.. and we want to store our users in a database rather than tomcat's xml file.. if I am mistaken on how this works please correct me =) (I havn't actually looked at it, I've just looked at tomcat's security restraint stuff before) -David - Original Message - From: Raible, Matt [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:47 AM Subject: RE: Webapp Security? How about using container managed security with tomcat's realms? It works great for me. Here's an example app if you're interested: http://tinyurl.com/fuvq HTH, Matt -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:27 AM To: Struts Mailing List 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? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: Webapp Security?
David Bolsover wrote: I ended up writing my own application security manager - when the user logs in, his permissions are loaded from DB and then checked before any action is performed - with appropriate errors if a violation is detected. Where are you doing the checking, in the Action? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
On Thu, 3 Jul 2003, Adam Hardy wrote: Date: Thu, 03 Jul 2003 13:47:20 +0200 From: Adam Hardy [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: Webapp Security?
HI, On a similar vein, I am running into a problem with web security and thought I will bounce it off all the gurus here in this forum. I am trying to do FORM based authentication and am using login.jsp with an action of j_security_check with SunOne App Server. The j_security_check seems to be redirecting(302) the output from login.jsp after authenticating.I need to collect the j_username and j_password from the request in my index.jsp.I tried using a Filter on /login.jsp and /index.jsp to change the status code from 302 to 200 but that did not work.I can't seem to put j_security_check in the web.xml as a servlet name or url pattern in the filter.How would I access the j_security_check ? I have used a simple login.jsp but my client wants to use Form based authentication. Thanks in advance, Vijay -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 10:35 AM To: Struts Users Mailing List Subject: Re: Webapp Security? On Thu, 3 Jul 2003, Adam Hardy wrote: Date: Thu, 03 Jul 2003 13:47:20 +0200 From: Adam Hardy [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] RE: Webapp Security?
On Thu, 3 Jul 2003, Vijay Balakrishnan wrote: Date: Thu, 3 Jul 2003 11:04:51 -0700 From: Vijay Balakrishnan [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: [OT] RE: Webapp Security? HI, On a similar vein, I am running into a problem with web security and thought I will bounce it off all the gurus here in this forum. I am trying to do FORM based authentication and am using login.jsp with an action of j_security_check with SunOne App Server. The j_security_check seems to be redirecting(302) the output from login.jsp after authenticating.I need to collect the j_username and j_password from the request in my index.jsp.I tried using a Filter on /login.jsp and /index.jsp to change the status code from 302 to 200 but that did not work.I can't seem to put j_security_check in the web.xml as a servlet name or url pattern in the filter.How would I access the j_security_check ? I have used a simple login.jsp but my client wants to use Form based authentication. When you are using form-based login, it is not appropriate to consider the login page itself to be part of your application -- instead, think of it as part of the container, reserved solely for the container's use. To get a feel for how this works dynamically, temporarily change your app to use BASIC authentication instead. See? There is no such thing as a login page, because it is a built in feature, and that is the way you should think of the login page for form-based login as well. When using form-based authentication, the login page is used (by the container) when an unauthenticated user tries to access a protected resource for the first time. The container saves the original request, and (after successful authentication), the redirect done by the container is to replay that original request. Again, the design goal of the whole process is to simulate the user experience of BASIC authentication (in that case, the browser is the one that replays the transaction, but it feels the same to the user). Trying to do something directly with the login page, then, is misusing this functionality. Even if you find a hack that works for one container, you can be pretty sure it won't be portable to anywhere else. After successful login, the username will be visible to your application by calling request.getRemoteUser(). You can programmatically check whether the authenticated user has a particular role, by calling request.isUserInRole(). The password is not visible, and IMHO that is exactly the way it should be -- using container managed security means that the application keeps its hands off of sensitive information like passwords. Thanks in advance, Vijay Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 10:35 AM To: Struts Users Mailing List Subject: Re: Webapp Security? On Thu, 3 Jul 2003, Adam Hardy wrote: Date: Thu, 03 Jul 2003 13:47:20 +0200 From: Adam Hardy [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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
Re: Webapp Security?
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 [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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 [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
On Thu, 3 Jul 2003, David Erickson wrote: Date: Thu, 3 Jul 2003 12:37:56 -0600 From: David Erickson [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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 [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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
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? Thanks -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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? 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 [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
On Thu, 3 Jul 2003, Rick Reumann wrote: Date: 03 Jul 2003 15:22:55 -0400 From: Rick Reumann [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
On Thu, 3 Jul 2003, David Erickson wrote: Date: Thu, 3 Jul 2003 13:44:41 -0600 From: David Erickson [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Webapp Security?
How about using container managed security with tomcat's realms? It works great for me. Here's an example app if you're interested: http://tinyurl.com/fuvq HTH, Matt -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:27 AM To: Struts Mailing List 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? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
Is it based on using security restraints and having all your users set into groups in the tomcat-users.xml file? If so our problem is we don't want to have users based into groups but want to give permissions to users individually to many different things.. and we want to store our users in a database rather than tomcat's xml file.. if I am mistaken on how this works please correct me =) (I havn't actually looked at it, I've just looked at tomcat's security restraint stuff before) -David - Original Message - From: Raible, Matt [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:47 AM Subject: RE: Webapp Security? How about using container managed security with tomcat's realms? It works great for me. Here's an example app if you're interested: http://tinyurl.com/fuvq HTH, Matt -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:27 AM To: Struts Mailing List 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? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Webapp Security?
David Erickson wrote: Is it based on using security restraints and having all your users set into groups in the tomcat-users.xml file? If so our problem is we don't want to have users based into groups but want to give permissions to users individually to many different things.. and we want to store our users in a database rather than tomcat's xml file.. if I am mistaken on how this works please correct me =) (I havn't actually looked at it, I've just looked at tomcat's security restraint stuff before) Tomcat ships with a security system just like the one you describe -- you set up permissions (both group-based *and* individual, so it actually does meet the needs you've described) and Tomcat checks this file to determine who can see what. This is called Tomcat's MemoryRealm. However, this is just to make it easy to play with and learn -- you are not restricted to using MemoryRealm to identify your security roles. You can also use JDBCRealm, DataSourceRealm, and JNDIRealm which can adapt to relational databases or other directories (LDAP etc). JNDIRealm is probably the most flexible, but if you're just using a simple relational database then you might just want to use JDBCRealm and spare yourself having to configure everything in JNDI. Take a look at this page: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Webapp Security?
If you want to give user's dynamic permissions at runtime, you could add a filter on top of container managed authentication (CMA). CMA is nice b/c you can use any authenticate with LDAP, a database (my example uses MySQL), or a flat file - or even an NT Domain. You'll probably have to setup some sort of system that defines who can see what - so you'll eventually (probably) end up implementing some sort of roles/groups - unless you're planning on checking for individual usernames or some such attribute before allowing access. Tomcat's security constraint stuff is the same thing as CMA. HTH, Matt -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:54 AM To: Struts Users Mailing List Subject: Re: Webapp Security? Is it based on using security restraints and having all your users set into groups in the tomcat-users.xml file? If so our problem is we don't want to have users based into groups but want to give permissions to users individually to many different things.. and we want to store our users in a database rather than tomcat's xml file.. if I am mistaken on how this works please correct me =) (I havn't actually looked at it, I've just looked at tomcat's security restraint stuff before) -David - Original Message - From: Raible, Matt [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:47 AM Subject: RE: Webapp Security? How about using container managed security with tomcat's realms? It works great for me. Here's an example app if you're interested: http://tinyurl.com/fuvq HTH, Matt -Original Message- From: David Erickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 11:27 AM To: Struts Mailing List 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? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
