You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Guy Thomas <gu...@vlaamsbrabant.be> on 2010/08/09 08:15:07 UTC
URL authentication
I am adding authentication to a Struts2 web application by implementing an authentication interceptor.
With an interceptor, as far as I understand, you can prevent non-authenticated perons from accessing specific actions.
However, suppose somebody forwards a URL to a specific pdf-file to a non-authenticated "outsider".
For example: http://.../persberichten/persbericht12954.pdf
Which Struts2 mechanism can I use to prevent the non-authenticated "outsider" from accessing that PDF?
Or, another example:
http://.../persoverzicht/ophalenpub.jsp?id=27859
Is it possible to prevent the outsider from accessing that specific press article?
-------------
Aan dit bericht kunnen geen rechten worden ontleend. Alle berichten naar dit professioneel e-mailadres kunnen door de werkgever gelezen worden.
Ondernemingsnummer: 0253.973.219
Re: URL authentication
Posted by Paweł Wielgus <po...@gmail.com>.
Hi,
there is one gotcha here,
interceptor or action based authorization is for actions and not for
resources files.
So if one want's to protect access to some kind of *.pdf files on server disk
one can set pdf as action extension in struts.properties
and create an action that will check if logged in user has right to
download this file
and return stream of requested file contents.
There is also a possibility to include parameter names after action name like
/namespace/action/1/2/3/mySecret.pdf
so that action can locate mySecret.pdf with help of these parameters
if that's necessary.
If there is a simpler way of acheving this
some please advice, i've just implemented such a scenario for my customer
and it would be very nice to make it simpler.
Best greetings,
Paweł Wielgus.
2010/8/10 Guy Thomas <gu...@vlaamsbrabant.be>:
> I was thinking of using declarative security (in web.xml) for resource authorization. Is this a good idea? Is it enough?
>
> -----Oorspronkelijk bericht-----
> Van: CRANFORD, CHRIS [mailto:Chris.Cranford@setech.com]
> Verzonden: maandag 9 augustus 2010 15:50
> Aan: Struts Users Mailing List
> Onderwerp: RE: URL authentication
>
> Pattern A:
>
> /unsecured/*
>
> Run whatever unsecured interceptors on these. This would not include the authentication interceptor or the allowed resource check interceptor. That's because these are considered OPEN to everyone.
>
> Pattern B:
>
> /secured/*
>
> Run the authentication check and the resource check interceptors.
>
> The authentication check would verify simply that the HttpSession object contains whatever credential token in memory. If this value doesn't exist, you simply don't have any authentication, return LOGIN as your result, sending the user to the login page. The neat thing we did when this happened in our application is we captured the original resource and any parameters, set that value to a page scope variable and stored it in the login form. This way when the user called the LoginAction, we could redirect the user to the original requestsed resource once we got their credentials.
>
> The resource check logic for us in my case was simple as well. When we grab the authentication object (User object that is), the object gets populated with a map of resources and their access permissions. This way the data is grabbed only once and gets stored in the session object only during login. Therefore, all resource checks simply verify that the user object contains the resource and desired access. There is no trip to the RDBMS on each web call, reducing the overhead. If a user's access changes during a session, it doesn't get updated. They simply logout and back in and the access is fixed.
>
> Lots of ways to do it, but I would keep them separate.
>
> Chris
>
>> -----Original Message-----
>> From: Dave Newton [mailto:davelnewton@gmail.com]
>> Sent: Monday, August 09, 2010 6:23 AM
>> To: Struts Users Mailing List
>> Subject: Re: URL authentication
>>
>> FWIW, I wouldn't combine the two into the same interceptor since
>> rather different things... plus resource access is more likely to take
>> in a different layer, and not be a cross-cutting concern.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
> -------------
> Aan dit bericht kunnen geen rechten worden ontleend. Alle berichten naar dit professioneel e-mailadres kunnen door de werkgever gelezen worden.
> Ondernemingsnummer: 0253.973.219
>
>
> ---------------------------------------------------------------------
> 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: URL authentication
Posted by Guy Thomas <gu...@vlaamsbrabant.be>.
I was thinking of using declarative security (in web.xml) for resource authorization. Is this a good idea? Is it enough?
-----Oorspronkelijk bericht-----
Van: CRANFORD, CHRIS [mailto:Chris.Cranford@setech.com]
Verzonden: maandag 9 augustus 2010 15:50
Aan: Struts Users Mailing List
Onderwerp: RE: URL authentication
Pattern A:
/unsecured/*
Run whatever unsecured interceptors on these. This would not include the authentication interceptor or the allowed resource check interceptor. That's because these are considered OPEN to everyone.
Pattern B:
/secured/*
Run the authentication check and the resource check interceptors.
The authentication check would verify simply that the HttpSession object contains whatever credential token in memory. If this value doesn't exist, you simply don't have any authentication, return LOGIN as your result, sending the user to the login page. The neat thing we did when this happened in our application is we captured the original resource and any parameters, set that value to a page scope variable and stored it in the login form. This way when the user called the LoginAction, we could redirect the user to the original requestsed resource once we got their credentials.
The resource check logic for us in my case was simple as well. When we grab the authentication object (User object that is), the object gets populated with a map of resources and their access permissions. This way the data is grabbed only once and gets stored in the session object only during login. Therefore, all resource checks simply verify that the user object contains the resource and desired access. There is no trip to the RDBMS on each web call, reducing the overhead. If a user's access changes during a session, it doesn't get updated. They simply logout and back in and the access is fixed.
Lots of ways to do it, but I would keep them separate.
Chris
> -----Original Message-----
> From: Dave Newton [mailto:davelnewton@gmail.com]
> Sent: Monday, August 09, 2010 6:23 AM
> To: Struts Users Mailing List
> Subject: Re: URL authentication
>
> FWIW, I wouldn't combine the two into the same interceptor since
> rather different things... plus resource access is more likely to take
> in a different layer, and not be a cross-cutting concern.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
-------------
Aan dit bericht kunnen geen rechten worden ontleend. Alle berichten naar dit professioneel e-mailadres kunnen door de werkgever gelezen worden.
Ondernemingsnummer: 0253.973.219
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: URL authentication
Posted by "CRANFORD, CHRIS" <Ch...@setech.com>.
Pattern A:
/unsecured/*
Run whatever unsecured interceptors on these. This would not include
the authentication interceptor or the allowed resource check
interceptor. That's because these are considered OPEN to everyone.
Pattern B:
/secured/*
Run the authentication check and the resource check interceptors.
The authentication check would verify simply that the HttpSession object
contains whatever credential token in memory. If this value doesn't
exist, you simply don't have any authentication, return LOGIN as your
result, sending the user to the login page. The neat thing we did when
this happened in our application is we captured the original resource
and any parameters, set that value to a page scope variable and stored
it in the login form. This way when the user called the LoginAction, we
could redirect the user to the original requestsed resource once we got
their credentials.
The resource check logic for us in my case was simple as well. When we
grab the authentication object (User object that is), the object gets
populated with a map of resources and their access permissions. This
way the data is grabbed only once and gets stored in the session object
only during login. Therefore, all resource checks simply verify that
the user object contains the resource and desired access. There is no
trip to the RDBMS on each web call, reducing the overhead. If a user's
access changes during a session, it doesn't get updated. They simply
logout and back in and the access is fixed.
Lots of ways to do it, but I would keep them separate.
Chris
> -----Original Message-----
> From: Dave Newton [mailto:davelnewton@gmail.com]
> Sent: Monday, August 09, 2010 6:23 AM
> To: Struts Users Mailing List
> Subject: Re: URL authentication
>
> FWIW, I wouldn't combine the two into the same interceptor since
> rather different things... plus resource access is more likely to take
> in a different layer, and not be a cross-cutting concern.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: URL authentication
Posted by Dave Newton <da...@gmail.com>.
FWIW, I wouldn't combine the two into the same interceptor since they're
rather different things... plus resource access is more likely to take place
in a different layer, and not be a cross-cutting concern.
Dave
On Mon, Aug 9, 2010 at 3:07 AM, Rahul Mohan <ra...@tcs.com> wrote:
> I think we are mixing two issues here. Authentication deals with verifying
> whether a user is what he/she claims to be and authorization is the
> mechanism for checking whether someone has access to a particular
> resource.
>
> The standard practice is to prevent unauthenticated users from accessing
> any resource within your app. This is typically done by an interceptor
> that allows a request to pass through only if it can find a user-specific
> token in the session. This should solve your first problem.
>
> The second question is about authorization, where a particular user is not
> having access to a particular resource. This can also be built into the
> same interceptor, but you will have to supply the authorization table
> somehow - usually from an LDAP or RDBMS.
>
> - Rahul
>
>
>
> From:
> Guy Thomas <gu...@vlaamsbrabant.be>
> To:
> Struts Users Mailing List <us...@struts.apache.org>
> Date:
> 09-08-2010 11:47
> Subject:
> URL authentication
>
>
>
> I am adding authentication to a Struts2 web application by implementing an
> authentication interceptor.
> With an interceptor, as far as I understand, you can prevent
> non-authenticated perons from accessing specific actions.
>
> However, suppose somebody forwards a URL to a specific pdf-file to a
> non-authenticated "outsider".
> For example: http://.../persberichten/persbericht12954.pdf
>
> Which Struts2 mechanism can I use to prevent the non-authenticated
> "outsider" from accessing that PDF?
>
> Or, another example:
>
> http://.../persoverzicht/ophalenpub.jsp?id=27859
>
> Is it possible to prevent the outsider from accessing that specific press
> article?
>
>
>
> -------------
> Aan dit bericht kunnen geen rechten worden ontleend. Alle berichten naar
> dit professioneel e-mailadres kunnen door de werkgever gelezen worden.
> Ondernemingsnummer: 0253.973.219
>
>
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
>
Re: URL authentication
Posted by Rahul Mohan <ra...@tcs.com>.
I think we are mixing two issues here. Authentication deals with verifying
whether a user is what he/she claims to be and authorization is the
mechanism for checking whether someone has access to a particular
resource.
The standard practice is to prevent unauthenticated users from accessing
any resource within your app. This is typically done by an interceptor
that allows a request to pass through only if it can find a user-specific
token in the session. This should solve your first problem.
The second question is about authorization, where a particular user is not
having access to a particular resource. This can also be built into the
same interceptor, but you will have to supply the authorization table
somehow - usually from an LDAP or RDBMS.
- Rahul
From:
Guy Thomas <gu...@vlaamsbrabant.be>
To:
Struts Users Mailing List <us...@struts.apache.org>
Date:
09-08-2010 11:47
Subject:
URL authentication
I am adding authentication to a Struts2 web application by implementing an
authentication interceptor.
With an interceptor, as far as I understand, you can prevent
non-authenticated perons from accessing specific actions.
However, suppose somebody forwards a URL to a specific pdf-file to a
non-authenticated "outsider".
For example: http://.../persberichten/persbericht12954.pdf
Which Struts2 mechanism can I use to prevent the non-authenticated
"outsider" from accessing that PDF?
Or, another example:
http://.../persoverzicht/ophalenpub.jsp?id=27859
Is it possible to prevent the outsider from accessing that specific press
article?
-------------
Aan dit bericht kunnen geen rechten worden ontleend. Alle berichten naar
dit professioneel e-mailadres kunnen door de werkgever gelezen worden.
Ondernemingsnummer: 0253.973.219
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you