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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
