AclPermissionEvaluator extendability and batch permission lookup

Expected Behavior

a) The AclPermissionEvaluator should be extensible, i.e. to do my own logic for checking multiple entries at once (in 1 query) or overriden checkPermission / resolvePermission behaviours or logic that reuses the private fields. The class is public and not final/sealed, so I would expect it to be extensible.

b) I think a hasPermissionMulti or an overridden hasPermission that internally utilizes the this.aclService.readAclsById(oids, sids); would make sense, as such a method already exists in AclService. I suggest the method signature public Map<ObjectIdentity, Boolean> hasPermissionMulti(Authentication authentication, Collection<Serializable> targetIds, String targetType, Object permission), similar to Map<ObjectIdentity, Acl> readAclsById(List<ObjectIdentity> objects) in JdbcAclService.

My use case here is, that @PostFilter'ing with hasPermission creates a separate request for each element, which leads to N+1 JDBC queries, whereas the aclService.readAclsById -> aclService.lookupStrategy.readAclsById does a batched load in the BasicLookupStrategy

Current Behavior

a) The following fields are private / default, even though they should be protected:

• private final AclService aclService;
• private ObjectIdentityRetrievalStrategy objectIdentityRetrievalStrategy
• private ObjectIdentityGenerator objectIdentityGenerator
• private SidRetrievalStrategy sidRetrievalStrategy

Same problems for the following methods:

• private PermissionFactory permissionFactory(...)
• private boolean checkPermission(...)
• List resolvePermission(Object permission)
• private Permission buildPermission(String permString)

This means, any extending class (i.e. apache kylin's acl permission evaluator) has to replicate these fields (example in kylin: permissionFactory).

This leads to potential bugs, like calling setPermissionFactory on the extending variant only setting the original AclPermissionEvaluator's permission factory, not the extending one - if the setters are not also overriden and set the super-setter + set the own field - which makes extending this class even more error prone. This is the case in Kylin.

b) There is no hasPermissionMulti and the proper way to check hasPermission on multiple objects is by using a custom SpEL / @PostFilter with N+1 performance.

Context

How has this issue affected you?
I currently have a CustomAclPermissionEvaluator extends AclPermissionEvaluator that is effectively a 100 line code clone, just to have my 10 line hasPermissionMulti/checkPermissionMulti - or accept N+1 queries in post-filtering.

What are you trying to accomplish?
a) Extensibility and customization of spring-security-acl, specifically making all the private/default fields and methods protected. This would make extended classes 20 lines instead of 120.
b) Optional: Performance, no N+1 queries, adding the suggested hasPermissionMulti to the spring implementation.

What other alternatives have you considered?
Are you aware of any workarounds?
Any person wanting to override the class can code clone the AclPermissionEvaluator, or use it as is and have bad N+1 performance.

Note I'm not affiliated with Apache/Kylin, I just used grep.app to look for extends AclPermissionEvaluator to check, if any public project had a similar issue.

Start with AclPermissionEvaluator and the referenced BasicLookupStrategy.readAclsById entry point, then review how the listed fields and methods currently constrain extensions. Done requires an agreed extensibility design and, if the batch option is accepted, a defined multi-object permission lookup behavior without the described N+1 access pattern.