RE: Webapp Security?

[du Plessis, Corneil C]

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 

__

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?

[Craig R. McClanahan]

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?

[Rick Reumann]

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?

[Edgar Dollin]

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 duri

Re: Webapp Security?

[Craig R. McClanahan]

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?

[Craig R. McClanahan]

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?

[Jamie M. Guillemette]

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?

[Dolf Starreveld]

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?

[David Erickson]

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?

[Rick Reumann]

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?

[Jamie M. Guillemette]

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?

[Dolf Starreveld]

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?

[Rick Reumann]

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?

[David Erickson]

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

Re: Webapp Security?

[Craig R. McClanahan]

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?

[Rick Reumann]

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?

[Erik Price]

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?

[Rick Reumann]

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]

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?

[David Erickson]

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?

[Jamie M. Guillemette]

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?

[Erik Price]

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 Erickson]

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: [OT] RE: Webapp Security?

[Craig R. McClanahan]

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 

[OT] RE: Webapp Security?

[Vijay Balakrishnan]

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: Webapp Security?

[Craig R. McClanahan]

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]

Re: Webapp Security?

[Erik Price]

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?

[David Erickson]

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

Re: Webapp Security?

[Adam Hardy]

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?

[Paul Thomas]

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]

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?

[David Bolsover]

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]

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?

[Jing Zhou]

- Original Message - 
From: "David Erickson" <[EMAIL PROTECTED]>
To: "Struts Mailing List" <[EMAIL PROTECTED]>
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: [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?

[Raible, Matt]

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]

Re: Webapp Security?

[Erik Price]

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:





Erik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Webapp Security?

[David Erickson]

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?

[Erik Price]

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?

[Raible, Matt]

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]