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
