You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "tarek.nabil" <ta...@isoft.ae> on 2005/05/25 12:12:42 UTC
Security in Struts
Hi everyone,
We're building a project using Struts and are about to start on the
security module. The requirements are that security should be fine
grained, which means that it can not be on the module level, but rather
on the JSP or Action level. Actually, the users might ask for security
on the button level, but we intend to push back on that one.
Are there any widely used approaches or best practices that we can
follow?
Note that we will not be using J2EE based authentication and security,
which means we have a custom login process.
Any suggestions are appreciated.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security in Struts
Posted by atta-ur rehman <at...@gmail.com>.
Hello Tarek,
I'd say front your application with a Servlet Filter that checks for
the security of the current page against security runles defined in
database/XML and probably cached for the current session to avoid
hitting database for every request.
ATTA
On 5/25/05, tarek.nabil <ta...@isoft.ae> wrote:
> Hi everyone,
>
> We're building a project using Struts and are about to start on the
> security module. The requirements are that security should be fine
> grained, which means that it can not be on the module level, but rather
> on the JSP or Action level. Actually, the users might ask for security
> on the button level, but we intend to push back on that one.
>
> Are there any widely used approaches or best practices that we can
> follow?
>
> Note that we will not be using J2EE based authentication and security,
> which means we have a custom login process.
>
> Any suggestions are appreciated.
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security in Struts
Posted by Aladin Alaily <st...@aladin.ca>.
Hi Tarek,
If you want action level security, just write a base action that
authenticates the user, and which all other actions extend. In the base
action, if the user is valid, then processing continues. Otherwise, the
user is redirected to the logged-out page. I would put this logic in
the Request Processor... but if you insist on having it in the Action,
then that works too. Ideally, this would go in a filter, but if you
don't have the facilities for filters, then they are of no use to you.
Quick question... what do you mean by "button level" authentication???
Hope this helps,
Aladin
tarek.nabil wrote:
> Hi everyone,
>
> We're building a project using Struts and are about to start on the
> security module. The requirements are that security should be fine
> grained, which means that it can not be on the module level, but rather
> on the JSP or Action level. Actually, the users might ask for security
> on the button level, but we intend to push back on that one.
>
> Are there any widely used approaches or best practices that we can
> follow?
>
> Note that we will not be using J2EE based authentication and security,
> which means we have a custom login process.
>
> Any suggestions are appreciated.
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security in Struts
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Hey, I'm not working! I'm avoiding doing some DIY!!! :)
Sorry for you though. I guess someone always has to work.
Actually I love CMA, but what put me off a while ago was when I realised
that CMA requires an implementation on the browser side that requires
the user to stay in SSL after HTTPS authentication - I wanted to encrypt
the password and then switch back out of SSL again to HTTP. CMA won't
let you do that. You lose access to the user & roles objects.
Hope you get a break soon.
Adam
On 30/05/05 13:03 Martin Gainty wrote:
> Adam
> I would take a look at finer grained security available thru
> security-constraints and web-resource-collection
> identifying the HTTP Method access capability for a specific role
> http://developers.sun.com/prodtech/appserver/reference/techart/access_control.html
>
> (If its any consolation you're not the only one that does NOT get today
> off as a paid holiday)
> Martin-
>
> ----- Original Message ----- From: "Eddie Bush" <ea...@swbell.net>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Monday, May 30, 2005 2:10 AM
> Subject: Re: Security in Struts
>
>
>> Adam,
>>
>> Nothing put me off CMA :-) I think it's fantastic, if it fits your
>> ticket. Unfortunately, in the environment I currently build apps for,
>> CMA is not feasible. Sometimes you get your druthers - sometimes you
>> look at the standard and decide how you can have your druthers, even
>> if others are busily trying to snatch them from your grasp!
>>
>> Ah - you're talking about my touting this as the "best approach", I
>> bet. Well, I'd rather use CMA where it's available, so I suppose I
>> misrepresented myself a tad. I like the approach I represented better
>> than what I've seen others in my shop take. Essentially, instead of
>> taking advantage of things that exist in the Servlet spec, they take
>> it upon themselves to create their own proprietary way of doing things
>> ... and it varies by application! I'm working on them ... only been
>> there a year - can't change everyone overnight ;-)
>>
>> Happy Memorial Day Everyone! :-D ... back to work Tuesday :-( ...
>> vacation coming soon though! :-D
>>
>> Later :-)
>>
>> Eddie
>>
>> ----- Original Message ----- From: "Adam Hardy"
>> <ah...@cyberspaceroad.com>
>> To: "Struts Users Mailing List" <us...@struts.apache.org>
>> Sent: Sunday, May 29, 2005 6:32 PM
>> Subject: Re: Security in Struts
>>
>>
>>> Eddie,
>>> what put you off CMA?
>>>
>>> if you don't mind me asking.
>>> Adam
>>
>>
>>
>>
>> ---
>> avast! Antivirus: Outbound message clean.
>> Virus Database (VPS): 0521-5, 05/29/2005
>> Tested on: 5/30/2005 1:10:55 AM
>> avast! - copyright (c) 2000-2004 ALWIL Software.
>> http://www.avast.com
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security in Struts
Posted by Martin Gainty <mg...@hotmail.com>.
Adam
I would take a look at finer grained security available thru
security-constraints and web-resource-collection
identifying the HTTP Method access capability for a specific role
http://developers.sun.com/prodtech/appserver/reference/techart/access_control.html
(If its any consolation you're not the only one that does NOT get today off
as a paid holiday)
Martin-
----- Original Message -----
From: "Eddie Bush" <ea...@swbell.net>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Monday, May 30, 2005 2:10 AM
Subject: Re: Security in Struts
> Adam,
>
> Nothing put me off CMA :-) I think it's fantastic, if it fits your
> ticket. Unfortunately, in the environment I currently build apps for, CMA
> is not feasible. Sometimes you get your druthers - sometimes you look at
> the standard and decide how you can have your druthers, even if others are
> busily trying to snatch them from your grasp!
>
> Ah - you're talking about my touting this as the "best approach", I bet.
> Well, I'd rather use CMA where it's available, so I suppose I
> misrepresented myself a tad. I like the approach I represented better
> than what I've seen others in my shop take. Essentially, instead of
> taking advantage of things that exist in the Servlet spec, they take it
> upon themselves to create their own proprietary way of doing things ...
> and it varies by application! I'm working on them ... only been there a
> year - can't change everyone overnight ;-)
>
> Happy Memorial Day Everyone! :-D ... back to work Tuesday :-( ... vacation
> coming soon though! :-D
>
> Later :-)
>
> Eddie
>
> ----- Original Message -----
> From: "Adam Hardy" <ah...@cyberspaceroad.com>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Sunday, May 29, 2005 6:32 PM
> Subject: Re: Security in Struts
>
>
>> Eddie,
>> what put you off CMA?
>>
>> if you don't mind me asking.
>> Adam
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 0521-5, 05/29/2005
> Tested on: 5/30/2005 1:10:55 AM
> avast! - copyright (c) 2000-2004 ALWIL Software.
> http://www.avast.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security in Struts
Posted by Eddie Bush <ea...@swbell.net>.
Adam,
Nothing put me off CMA :-) I think it's fantastic, if it fits your ticket.
Unfortunately, in the environment I currently build apps for, CMA is not
feasible. Sometimes you get your druthers - sometimes you look at the
standard and decide how you can have your druthers, even if others are
busily trying to snatch them from your grasp!
Ah - you're talking about my touting this as the "best approach", I bet.
Well, I'd rather use CMA where it's available, so I suppose I misrepresented
myself a tad. I like the approach I represented better than what I've seen
others in my shop take. Essentially, instead of taking advantage of things
that exist in the Servlet spec, they take it upon themselves to create their
own proprietary way of doing things ... and it varies by application! I'm
working on them ... only been there a year - can't change everyone overnight
;-)
Happy Memorial Day Everyone! :-D ... back to work Tuesday :-( ... vacation
coming soon though! :-D
Later :-)
Eddie
----- Original Message -----
From: "Adam Hardy" <ah...@cyberspaceroad.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Sunday, May 29, 2005 6:32 PM
Subject: Re: Security in Struts
> Eddie,
> what put you off CMA?
>
> if you don't mind me asking.
> Adam
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0521-5, 05/29/2005
Tested on: 5/30/2005 1:10:55 AM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security in Struts
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Eddie,
what put you off CMA?
if you don't mind me asking.
Adam
On 28/05/05 19:00 Eddie Bush wrote:
> Tarek,
>
> Java provides a standard mechanism for you to tell if the person
> accessing your application has a certain permission. This is available
> through request.isUserInRole(String). Unfortunately, that only works
> for Container-Managed Authentication (CMA). You can make it work
> without using CMA, but it takes a little (not too much) work.
>
> Firstly, a Filter instance that is mapped to all your actions (and JSPs
> if you access them directly and they need security). This filter is
> really simple - if the user isn't authenticated, it sends them to the
> login page. If they are authenticated, the filter lets them pass
> through. There is one additional responsibility that I'll address later.
>
> Your login process authenticates your users and puts a bean out in the
> session to indicate the person is logged in - which is how your Filter
> knows they are logged in. I would recommend to you that the class for
> this bean implement java.security.Principal, since you can then use
> request.getUserPrincipal() to retrieve your bean (caveat later). Your
> login process will, additionally, determine the permissions that the
> person logging in has and make those available somehow in the session
> (my user bean actually stores these).
>
> Now, the caveat I spoke of:
>
> To make request.getUserPrincipal() and request.isUserInRole(String)
> work, you're going to have to write an HttpServletRequestWrapper
> implementation. This is very straight-forward and shouldn't take long.
> What you do here is to implement getUserPrincipal() to return the user
> bean after having retrieved it from the session - under the key you
> bound it to in your login process. Piece of cake! You'll also overload
> isUserInRole(String) to retrieve the users roles and determine if the
> passed-in parameter is in their list of roles. Again - piece of cake!
>
> Your Filter's additional responsibility:
>
> Before calling doChain(request, response), you'll want to wrap the
> request with an instance of your request wrapper. This is the trick
> (aka Magic!) that makes your application able to use standard methods
> available on the request.
>
> It sounds kind of cumbersome - complex, even - but once you start down
> the road, you'll soon see that it isn't much work at all. You *might*
> spend a day on all of this - two or three if you're totally unfamiliar
> with everything I've spoken about and have to do some research. This is
> - far and above - the best approach, but there's actually one better, if
> you can use it:
>
> http://securityfilter.sourceforge.net
>
> Essentially, the security filter project does what I just said you
> needed to do, but it doesn't provide database access to all RDBMS yet.
> Depending on how closely you want to simulate CMA and depending on if
> they have an adapter for your RDBMS, you might be better off
> implementing what I spoke of above yourself. For me, I wanted to see
> what role a person had inside of an action. It was easier for me to
> grow my own than write an adapter and have to learn how to use
> SecurityFilter. That may not be the case for you.
>
> Hope that helps!
>
> Eddie Bush
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security in Struts
Posted by Eddie Bush <ea...@swbell.net>.
Tarek,
Java provides a standard mechanism for you to tell if the person accessing
your application has a certain permission. This is available through
request.isUserInRole(String). Unfortunately, that only works for
Container-Managed Authentication (CMA). You can make it work without using
CMA, but it takes a little (not too much) work.
Firstly, a Filter instance that is mapped to all your actions (and JSPs if
you access them directly and they need security). This filter is really
simple - if the user isn't authenticated, it sends them to the login page.
If they are authenticated, the filter lets them pass through. There is one
additional responsibility that I'll address later.
Your login process authenticates your users and puts a bean out in the
session to indicate the person is logged in - which is how your Filter knows
they are logged in. I would recommend to you that the class for this bean
implement java.security.Principal, since you can then use
request.getUserPrincipal() to retrieve your bean (caveat later). Your login
process will, additionally, determine the permissions that the person
logging in has and make those available somehow in the session (my user bean
actually stores these).
Now, the caveat I spoke of:
To make request.getUserPrincipal() and request.isUserInRole(String) work,
you're going to have to write an HttpServletRequestWrapper implementation.
This is very straight-forward and shouldn't take long. What you do here is
to implement getUserPrincipal() to return the user bean after having
retrieved it from the session - under the key you bound it to in your login
process. Piece of cake! You'll also overload isUserInRole(String) to
retrieve the users roles and determine if the passed-in parameter is in
their list of roles. Again - piece of cake!
Your Filter's additional responsibility:
Before calling doChain(request, response), you'll want to wrap the request
with an instance of your request wrapper. This is the trick (aka Magic!)
that makes your application able to use standard methods available on the
request.
It sounds kind of cumbersome - complex, even - but once you start down the
road, you'll soon see that it isn't much work at all. You *might* spend a
day on all of this - two or three if you're totally unfamiliar with
everything I've spoken about and have to do some research. This is - far
and above - the best approach, but there's actually one better, if you can
use it:
http://securityfilter.sourceforge.net
Essentially, the security filter project does what I just said you needed to
do, but it doesn't provide database access to all RDBMS yet. Depending on
how closely you want to simulate CMA and depending on if they have an
adapter for your RDBMS, you might be better off implementing what I spoke of
above yourself. For me, I wanted to see what role a person had inside of an
action. It was easier for me to grow my own than write an adapter and have
to learn how to use SecurityFilter. That may not be the case for you.
Hope that helps!
Eddie Bush
----- Original Message -----
From: "tarek.nabil" <ta...@isoft.ae>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Wednesday, May 25, 2005 5:12 AM
Subject: Security in Struts
Hi everyone,
We're building a project using Struts and are about to start on the
security module. The requirements are that security should be fine
grained, which means that it can not be on the module level, but rather
on the JSP or Action level. Actually, the users might ask for security
on the button level, but we intend to push back on that one.
Are there any widely used approaches or best practices that we can
follow?
Note that we will not be using J2EE based authentication and security,
which means we have a custom login process.
Any suggestions are appreciated.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0521-4, 05/27/2005
Tested on: 5/28/2005 1:00:50 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org