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…
Questions:
1) Spring uses a pre-defined set of ACL tables for its security entries? so your custom PERMISSION tables are only to keep auditing records for the Permissions defined using Spring Security? Why not use a trigger to populate a separate table.
2) I’m curious of the last para: how without pre-defining ACLs using SQL scripts do you manage to pre-define them via ServletContextListener – you have the ACLs hard-coded?
Spring Security has a suggested table structure, but you still have to define the schema. For performance reasons (I believe), they define acl_entries, acl_sid and acl_object_identity, but no actual acl table. The information that would go on the acl table is actually repeated on each each acl_entry (see paragraphs 4 and 5). My permission table is just that missing acl table, renamed.
The auditing being discussed here is more like log4j (fairly dynamic, easily configured by devs), than the database table auditing. Aside from auditing, I removed repeated information from the entries table (as I said, up to 3 pieces of information), and put them on the permission record.
I call a delegate that knows the default business logic for applying security to certain objects. The same logic that went into defining the initial security entries before, in SQL, is being done now, programmatically.
hmmm..are u sure about the missing table? as i see from the docs (and I could be way off, no expert on Spring) – An ACL (who/has-Permission/to-What) seems to be represented sufficiently in the ACL_ENTRY table using the association: Principal|Who(FK ACL_SID) + Resource|What(FK ACL_OID) + Permission(column BIT_MASK). You can then add additional rows for your custom permissions to the ACL_ENTRY table.
Seems limiting that your resources have to be represented as explicit object identities with class names.
So essentially, your security assignments are hardcoded somewhere – aren’t these usually configurable to the whim of the users rather than laid out to biz rules (is the case here anyways).
In their actual Acl implementation (AclImpl), and in the SQL queries they use to build the object, they compile the acl_entries based on the target object. In their documentation, they state,
and…
To respond to your hard-coded question: Initial security is hard-coded.
In one of my projects, the user must decide and specify who has access to what.
However, in this project, the security is decided by who they choose to collaborate with. Once the collaboration is complete (by exception or end of work), the security to that resulting document becomes a READ for everyone involved.
I meant to say ACE = (who/has-Permission/to-What). Yes, ACL exists as an Object/Concept that queries & groups ACE’s by an OID, an alternate grouping (in another framework) could have been by SID|Principal but in either case still don’t see ACL equating to an additional table. Also, If you are using the PERMISSION* tables to replace the Spring’s ACE, OID, SID table-names then you may be stretching the meaning of the term ‘Permission’.
I originally posted an image of the permission schema (see 2nd image). I just renamed Acl to Permission. Same concept, except I have a an actual table for Permission, while they put the fields that would have gone into the acl table into the acl_entries.