Almost two years ago, I said I would upgrade my my Hibernate-Acegi (Spring Secuirty) implementation to Spring Security’s new(er) ACL service paradigm. Here’s their suggested schema. Below is a class diagram of that paradigm.
Back then, none of projects required groups or users to inheriting permissions. I simply gave permissions to the roles and individuals that needed them. So, I used an AffirmativeBased AccessDecisionManager, and placed a RoleVoter before any other AbstractAclVoter. Simple, and it worked. One of my newer projects, however, does require the inheriting permissions.
What else…
Since I always use GUIDs, I still don’t need Spring Security to know the the domain class. But I’d like to utilize the new auditing feature. I’d also like to turn on and off auditing at the permission entry level. All in all, the upgrade wasn’t too bad at all. I had move some code from the SimpleAclEntry (deprecated) to the BasePermission. I actually extended the BasePermission, as the javadocs suggest.
Spring-Security’s distributed example code uses JDBC. Which is fairly straight-forward. It keeps a good amount of the information on the acl entry table. Thus no real need for a parent acl table. Well, since I’m using Hibernate, a few things automatically change:
- Built-in 2nd level caching (ehache for me)
- Ability to define granular joins and fetches based on the context
Based on those two (three?) items, I was able to normalize a good amount of information back to a new parent table permission (acl?). Now permission entries can focus on one purpose, facilitating a relationship between their parent permission and the target SID (Secure ID). See my pared-down ERD for this:
I’m not big on defining AOP behavior via the newer namespaced expressions. So, in that context, I stayed with what I had before. Some other things have been deprecated, such as BasicAclEntryAfterInvocationProvider, in favor of AclEntryAfterInvocationProvider. Overall, it was pretty painless.
One more thing…
When it comes to ACLs, the was one thing that drives me crazy is having to define the default relationships in SQL scripts. I freaking hate it. Well, I was able to resolve that this time around: Added a task and some delegation to my existing ServletContextListener. At application start, it goes about finding existing objects that need securing, that aren’t already secured. Yeah, that’s great…
