BasicAclEntryVoter for multiple objects

[garyfisher]

I'm evaluating Acegi Security for my recent project. I'd need to use ACL security so I went through the sample application. Everything looks fine except defining ACL access to methods. According to the sample application it looks like I'd need to define several bean's of type BasicAclEntryVoter for EVERY secured domain object.
Is it possible to define only one BasicAclEntryVoter for all types of domain objects? Is it neccessary to define a bean for each set of required roles (ie. aclContactDeleteVoter, aclContactAdminVoter in sample app.)? Or am I missing something?

Thanks
Pavel

[Ben Alex]

BasicAclEntryVoter requires the processDomainObjectClass property to reflect the Class of domain object the instance of the voter is meant to protect. This is necessary so the voter instance knows which method argument it is protecting by requiring a certain permission, as expressed by the requirePermission property.

You are free to write your own AccessDecisionVoter that implements alternative logic. For example, you might have a common business object abstract superclass that could be detected to resolve which method argument should be passed to the AclManager. You could have some properties for things like if no arguments match (probably vote to abstain) or which argument to use if there is more than one BusinessObject argument. Also what to do if one BusinessObject indicates ACLs authorizing the current principal, but a different BusinessObject argument does not authorize the current principal. It's a bit of a complexity reflecting all possible situations, but if you carefully consider your requirements you'll probably find a custom AccessDecisionVoter is quite viable.

[garyfisher]

Thanks Ben
I guessed I'd have to write my own AccessDecisionVoter, but I wanted to be 100% sure before starting to work on it. Using BasicAclEntryVoter would mean tens of bean declarations even in a small project and this would lead to code generation (xdoclet or custom solution). Do you think that it is possible to make it easier with commons annotations?
Pavel

[garyfisher]

I went through the source code in BasicAclEntryVoter and now I understand why it's not so easy to design more general decision voter. Nevertheless I will try to create my own decision voter to support a list of domain object classes (or an ant like expr defining a set of classes) and to check all of the arguments passed to the method invocation. I hope this could make my life easier when adding new domain objects to my project.

What do you think about it, Ben? Hasn't anyone written something similar?

Thanks

[Ben Alex]

I am not aware of any alternative AccessDecisionVoters that use ACL capabilities. My previous post listed some ideas to explore if you wanted to write one. If it also has unit tests, I'd be pleased to add it to Acegi Security.

On the issue of using attributes, MethodSecurityInterceptor works with a MethodDefinitionSource that internally generates a ConfigAttributeDefinition for each method pattern. The ConfigAttributeDefinition stores ConfigAttribs internally. You can build any ConfigAttrib concrete implementation you like. You can use attributes to build complex ConfigAttribs that a custom AccessDecisionVoter might wish to process. That may be a way of extracting more flexibility/power out of a single AccessDecisionVoter and less XML-based configuration.