I agree with your assessment Ben. Had many of those thoughts myself as I was pondering our situation. In the end we went with VOTERS DETECT OBJECT AS PARAMETER AND QUERY ACL OBJECT. Seems like the best choice for us since we only want to deny or allow access not mutate or filter properties of the object.
----------------------------------------- Andres March Platform - Apps Engineering Sony Online Entertainment desk: 858.577.3373 cell: 619.519.1519 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Ben Alex > Sent: Thursday, July 22, 2004 5:16 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Acegisecurity-developer] Instance based security > > Andy Depue wrote: > > >Has any thought been given to adding instance based security support to > Acegi? > >This seems to be a common requirement. > > > > > There are so many ways of approaching instant-level security, as touched > on by the other replies to this thread. The major issues are "where to > get the domain instance specific ACL information from" and "how to > change any returned value". > > I've copied this to the RCP list as they probably have some views on the > optimal approach, and which they'd like to see demonstrated in Petclinic > RCP. > > Here is a quick summary of the main ways to approach instance-level > security from an Acegi Security perspective: > > BUSINESS METHODS DO SECURITY THEMSELVES. This isn't as bad as it sounds. > Business methods can simply access the ContextHolder and obtain the > Authentication object. That way they can filter etc as they see fit. > Advantages: simple, no infrastructure required, can change the returned > object. Disadvantages: couples business code to Acegi, more difficult to > test as there is limited separation of concerns (though you can write > separate utility classes to help overcome this). > > VOTERS DETECT OBJECT AS PARAMETER AND QUERY EXISTING > GrantedAuthority[]s. In this case you add custom GrantedAuthority[]s to > the Authentication object during the original authentication process. > Later the voter looks up those authorities and authorizes access to the > domain instance accordingly. I'm presently using this approach in the > Petclinic RCP sample (still being written, yet to be checked in). > Advantages: simple, easy to test. Disadvantages: not scalable to > thousands of instances, must customise the AuthenticationProvider (or > AuthenticationDao if using DaoAuthenticationProvider), cannot change the > returned object. > > VOTERS DETECT OBJECT AS PARAMETER AND OPEN ACTUAL INSTANCE. This is used > in the Contacts sample application. A voter handles detecting a method > invocation concerning an identity, opens the domain instance, calls a > getter to obtain the ACL (access control list) information, and a > comparison is made to the Authentication object. Advantages: fairly > simple, easy to test. Disadvantages: opens a domain instance twice (in > the voter and again in the business method), cannot change the returned > object. > > VOTERS DETECT OBJECT AS PARAMETER AND QUERY ACL OBJECT. This would be a > variation on the above option, but instead of opening the target domain > instance twice, an ACL manager object would be consulted to obtain the > instance-specific privileges. Advantages: highly decoupled from the > domain objects, addresses performance issues, simple to test the parts, > easily offers ACL inheritance, administration tools have a central > reference point for all application ACL information. Disadvantages: > getting complex, cannot change the returned object. > > MethodSecurityInterceptor CALLS A RESULT PROCESSOR. This would be done > so that a list of classes can routinely be applied against the object > returned from a method invocation. These classes could do things like > Andy needs, such as obfuscate properties etc. If we went with the "voter > backed with an ACL manager" approach on the way into the method > invocation, these classes can easily determine which mutations they > should perform on the returned object. The only requirement would be the > classes should not throw an exception, as the business methods have > already taken place. An issue is how mutated values would affect ORM if > they were subsequently re-presented for committing. How do you handle > this, Andy? > > Comments? Preferences? > > Best regards > Ben > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Acegisecurity-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
