Data/Access Security in Struts2

["CRANFORD, CHRIS" <Ch...@setech.com>]

I realize this may not be directly related to Struts 2 but often times I
have found that many of us take different approaches to solve a common
problem and wanted to ping others as to your experience and
implementations regarding data security, particularly row-level in a
Struts 2 application that leverages both Spring Security 3 and Hibernate
3.6.

In particular, I am needing to implement security at both the method
invocation point of the service tier of the application along with
controlling once access is granted what records within that method are
available versus not available.

I have considered having a Spring permission evaluator to handle the
pre-authorizations on method invocations of the Service-tier, but I am
somewhat unsure whether to leverage Hibernate Filters or another means
to control what records are applicable.

For user A, records within GROUP 1, 2, and 3 may be applicable for one
method where-as for another method maybe within the same service or
another service could be limited to only records in GROUP 1.  For
another user, they may have a more restrictive or even broader list of
GROUPs for the same methods.  In some cases, more GROUPs maybe available
for view for users but they can only perform CRUD based activities on a
subset of those GROUPs too.

What have others explored, pain-points you've encountered, and found
useful.  Security and data access is often very application specific, so
I realize that my constraints are likely unlike the needs of other
applications, but the experiences learned are often common regardless.

Chris 



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Data/Access Security in Struts2

[Burton Rhodes <bu...@gmail.com>]

IMHO, if Spring can solve all the security requirements you need, I
would stick with one technology for security.  Adding another layer of
security with another technology (e.g. Hibernate) *may* complicate
code maintainability.  I have not delved into Hibernate security, but
"keep it simple stupid" is a pretty good motto to follow when you can.

On Wed, Mar 23, 2011 at 8:51 AM, CRANFORD, CHRIS
<Ch...@setech.com> wrote:
> I realize this may not be directly related to Struts 2 but often times I
> have found that many of us take different approaches to solve a common
> problem and wanted to ping others as to your experience and
> implementations regarding data security, particularly row-level in a
> Struts 2 application that leverages both Spring Security 3 and Hibernate
> 3.6.
>
> In particular, I am needing to implement security at both the method
> invocation point of the service tier of the application along with
> controlling once access is granted what records within that method are
> available versus not available.
>
> I have considered having a Spring permission evaluator to handle the
> pre-authorizations on method invocations of the Service-tier, but I am
> somewhat unsure whether to leverage Hibernate Filters or another means
> to control what records are applicable.
>
> For user A, records within GROUP 1, 2, and 3 may be applicable for one
> method where-as for another method maybe within the same service or
> another service could be limited to only records in GROUP 1.  For
> another user, they may have a more restrictive or even broader list of
> GROUPs for the same methods.  In some cases, more GROUPs maybe available
> for view for users but they can only perform CRUD based activities on a
> subset of those GROUPs too.
>
> What have others explored, pain-points you've encountered, and found
> useful.  Security and data access is often very application specific, so
> I realize that my constraints are likely unlike the needs of other
> applications, but the experiences learned are often common regardless.
>
> Chris
>
>
>
> ---------------------------------------------------------------------
> 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