RoleHierarchyVoter ACLs

[adam_jh]

I was just following the acl tutorial (http://server.denksoft.com/wordpress/?page_id=5) and following the follow-up advice (http://forum.springframework.org/showthread.php?t=59807). I went to use the RoleHierarchyVoter and all seems well but I assumed that the hierarchies apply not just for ui or method based security, but acls too. It appears this is not the case?

I was hoping to set an acl for eg a 'ROLE_SALES1' and have an admin ROLE_ADMINSALES have access to all the sales data (so there is less data db 'hard' coded), but although the admin can get to the method, the AFTER_ACL_READ prevents access. I determined that the AclEntryAfterInvocationProvider has a SidRetrievalStrategy which pays no attention to the hierarchies. Also, the <security:custom-after-invocation-provider/> doesn't seem us to allow to change the retrieval stragety.

Looks like its back to the deprecated UserDetailsServiceWrapper instead of RoleHierarchyVoter. Seems others are thinking this too for other reasons...http://jira.springframework.org/browse/SEC-883 and http://forum.springframework.org/sho...994#post185994

Any thoughts Luke?

[Luke Taylor]

I guess we could de-deprecate the wrapper option and offer both approaches, but ideally I'd like to have the ability to plug in the role hierarchy where required. You can set the SidRetrievalStrategy on AclEntryAfterInvocationProvider, so that should still be customizable, even if the existing class doesn't support resolution via a role hierarchy at the moment.

[adam_jh]

Thanks Luke,

Am more than happy to follow your preferred approach. Yes, it seems I can set the SidRetrievalStrategy - on the afterAclRead and afterAclCollectionRead beans, but I will probably follow the wrapper approach for now to avoid my custom code. If you wanted to point me in the place where you would be thinking of changing the code I could start a jira.

adam