spring-security: how much customization is wise?

Question

How much custom implementation is wise when it comes to spring security? How optimized is it or what parts are optimized the most and where should one not custom implement unless absolutely neccessary?

I'm wondering this as I am thinking of a way to implement dynamic ACLs that grant or revoke principal access for a single object as well as all objects of that type or even any String identifier. If i want to be able to say

@PreAuthorize("hasPermission(#person, details)")
public void getDetailsForPerson(Person person)

as well as

@PreAuthorize("hasPermission('package.path.Person', read)") 
public void getAllPersons()

as well as

@PreAuthorize("hasPermission('Person', read)") 
public void getAllPersons()

as well as

@PreAuthorize("hasPermission(#id, 'package.path.Person', read)")
public void getOnePerson(int id)

I will have to implement PermissionEvaluator. Now while I'm at it, why whould I use the exact spring-security ACL datamodel (as documented in the Spring Security Reference Appendix A.3 ) instead of implementing my own? I'll have to implement my own ACLService anyway if I want to allow permission evaluation for object types or strings as well as instances of objects.

Same for the ObjectIdentity Lookups: I'll have to implement those myself as well as I want to generate a OID from an @Entitys serialVersionUID to be able to grant access to a type permissions.

So as I am thinking of more and more things to custom implement, I am wondering, if I am still on the right track. Looking at tutorials like the Denksoft blog. I feel like I am missing out on a lot of spring-security's capabilities we might need later on. Or is it just that spring-security is very powerful and complex in case you need it but if you want to, you can do most of it yourself and just use the general framework to hold it all together?

Or am I creating potential security holes by not sticking to the tested implementations? Is what I have in mind already dangerous or still acceptable from a security and software design standpoint since I stick to the interfaces provided by spring-security? I haven't customized too many given implementations yet...

So... Thoughts on what we are planning to do (permissions for types as well as objects) as well as customizing spring-security would be very welcome.

Cheers!

Answer 1

Hm, no one seems to want to share their experience, thoughts or tips concerning the customization of spring security here, so I'll mark this as answered.

In short what we ended up doing was to custom-implement all spring security interfaces that interact with the database to use our own JPA/Hibernate access stack. That meant implementing

Authentication:

• CustomerDetailsService to handle our account table
• RoleHierarchy to resolve our own hierarchy table (1:n relation to Role which has a m:n to Account)
• PersistentLoginToken to persist the remember-me token inside our DB

For our special Access Control List that also supports setting permissions for all objects of a type:

• MutableAclService, Acl, AccessControlEntry and LookupStrategy to build the ACLs
• PermissionEvaluator to support class type (as String) arguments

So all in all quite a bit of work and there are still some things our implementation lacks. Was it worth it? Certainly, as we now have a lot more control, more flexibility and new features. Is it stable? We shall see, 45 unit tests so far for the custom implementations sounds like much but it really isn't.