SEC-2616: PermissionEvaluator chain-of-responsibility implementation

Christopher Smith (Migrated from SEC-2616) said:

I'm building an application where the domain security policy is built up from a number of independent rules (e.g., user A can give user B temporary permission to upload files to user A's account: hasPermission(owner, 'upload')), and it seems that these rules should be assembled in a Chain of Responsibility, similar to chaining logic present elsewhere in Spring Security. As I understand the architecture, the system expects exactly one PermissionEvaluator to be present, in contrast with the way that MessageConverters register for particular pairs of classes.

Would it be appropriate to add a PermissionEvaluatorChain implementation that ran through a series of permit/deny/pass rules to the main Spring Security distribution? If so, would directly adding support for building and configuring rule-based permission evaluators fit with the plans for upcoming versions (4.1 or so)?

Start by reviewing Spring Security's PermissionEvaluator architecture and the existing chaining logic referenced in the issue, then compare it with how MessageConverters register for class pairs. Determine whether a PermissionEvaluatorChain and rule-based permit/deny/pass support fit the project plans; done means a concrete design decision and agreed scope.