On my current project, we have a number of authorization requirements for a brand spanking new J2EE web application. We're already using Spring Acegi for authentication (Kerberos against an Active Directory server), so it made sense to use it for authorization too. The basic approach Acegi uses employs the notion of secure objects - basically, you can wrap security around a method invocation through an Acegi interceptor, and then advice can be applied to that method invocation via Spring AOP or AspectJ.
One of the challenging things about our project is the security requirements go down to the field level (i.e. only users in certain roles can see certain fields). We are using Hibernate, so ostensibly this would appear not present a problem, as this boils to just wrapping security around the getters and setters of the domain objects. Now, using Spring AOP is right out, because the domain objects aren't managed by Spring (not to mention the fact I don't like the Spring AOP proxy being wrapped around every object). So, you've no choice but to use AspectJ, which is fine and dandy, even though it adds a bit more complexity. However, what I found was that restricting access in this way interferes with how Hibernate works, and you get some strange behavior, the likes of which I won't go into. So, after much ado, I found a solution. You can configure Hibernate to use reflection (instead of the getters and setters) by doing the following on the secure fields:
Now, I can write advice for the getters and setters to enforce security, and Hibernate can access the object unhindered.
Alas, I'm not completely out of the woods, as the presentation layer must also be considered. The pattern described above relies on Acegi deciding on an user access when each method is called. However, on the front-end, you need to know a user's access (i.e. no access, read only, or full control), before the setter is even called. So, when the page which needs the data is loaded, I have a method which iterates through the getters and setters of the domain objects (using reflection) and builds a Map of permissions which can then be used by the JSP for conditional display logic. I don't entirely like this design, and I'm worried about latency when the JSP is called, but I can't come up with anything more elegant in which the Acegi securityContext remains the sole authorization authority.
I suspect they'll be a part 2 to this, if you have any thoughts, I'd appreciate them.
Comments
The problem about Hibernates private access to objects is the way it is implemented because it uses Reflection API. At first it's slower and therefore expensive. AspectJ often uses reflection, too. You will get into trouble, if you have a App-Server configured like supposed by the J2EE spec, which recommends to deny 'ReflectPermission'.
I ran into the same trouble and I am still searching for a better solution. So, did you find a solution?
Thank you, Timo
Sounds like a good idea...I think I'll go run that. ;)
Post new comment