Re: [Acegisecurity-developer] PostInvocation and Hibernate Sessions
We utilized a Hibernate interceptor in our solution, though that is only a part of the solution (the interceptor didn't give us everything we needed). - Andy On Wednesday 09 February 2005 09:40 pm, Ben Alex wrote: Gavin Terrill wrote: We recently adopted Acegi Security for one of our enterprise products security requirement, and we will be facing the same issues, so this thread is very useful and timely. Thought out of the blue: instead of mutating the domain objects, would it be possible to wrap them up in a dynamic 'secure' proxy? The proxy would essentially act in the role of a 'caretaker' (http://c2.com/cgi/wiki?CaretakerPattern), preventing access to the secured properties. I guess the downside would be that a dynamic proxy would require your domain objects implementing an interface, which may be cumbersome. Ok, what about utilizing CGLIB to extend the class then (MethodInterceptor)? I have previously played with GCLIBing domain object instances, but that caused some complications with Hibernate. In the end that's what motivated me to write the AspectJ integration, but I was disappointed by the poor incremental compilation reliability in the Eclipse IDE. That's going back probably six months, so it might have improved and using AspectJ is a realistic/viable option for a caretaker-style solution to method invocation. Alternatively, I am just wondering if a Hibernate Interceptor (http://www.hibernate.org/hib_docs/api/net/sf/hibernate/Interceptor.html) might be able to help in this case? It seems to offer the necessary hooks to introspect the object. Ben --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] PostInvocation and Hibernate Sessions
In our model, the lazy approach wouldn't have bought us too much since we have rich clients, meaning that all service invocations happen remotely. One of our goals was to prevent sensitive information from even being transmitted to the client. This means that we would have had to apply the lazy ACL before transmitting the objects to the client anyway. We considered the caretaker approach at first, and I think it is a very good idea. The downside is that it would require you to either define a different access strategy for your domain objects (instead of plain POJO get/set methods) or proxy/AOP your domain objects. This is perfectly acceptable in many cases, and again, is a good solution. In our case it would not have interacted well with other requirements. - Andy On Thursday 10 February 2005 07:58 am, Tim Kettering wrote: I am quite relieved to find that I'm not the only person facing this issue. The discussion so far is quite invaluable and I hope we can continue this thread. I have tried looking at Hibernate Interceptor, but I don't think it is the ideal solution because not all of my objects are obtained by Hibernate (most of them are, but not all). So I need whatever solution that I ultimately go with to work outside of Hibernate. To me, it seems the following conditions are important if we are looking at scrubbing the object instance. 1. ability to apply specific security to variable, or method level granularity. 2. persistence strategy independent. 3. ideally participate in the same transaction as the data load itself to guarantee a consistent version of the data. For the last option - however, if a caretaker pattern is applied, then caretaker implementation itself might choose to take a more lazy-load approach, not actually checking ACL permissions until the method is actually invoked. Is that a feasible option? This particular approach would happen outside the transaction though, so there could be a mismatch in the database object graph and the instanced object. -tim I have previously played with GCLIBing domain object instances, but that caused some complications with Hibernate. In the end that's what motivated me to write the AspectJ integration, but I was disappointed by the poor incremental compilation reliability in the Eclipse IDE. That's going back probably six months, so it might have improved and using AspectJ is a realistic/viable option for a caretaker-style solution to method invocation. Alternatively, I am just wondering if a Hibernate Interceptor (http://www.hibernate.org/hib_docs/api/net/sf/hibernate/Interceptor.html) might be able to help in this case? It seems to offer the necessary hooks to introspect the object. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] PostInvocation and Hibernate Sessions
How would that solve this flow: 1. Get object from service call (the object has been modified by ACL security). 2. Change object. Something like obj.setProperty(newValue) or obj.addSomething(something) or obj.getSomeSet().add(something) 3. Pass changed object to service method for processing (persisting). At step #3 you want to persist the changes that were made by the client but not the changes made by ACL filtering. - Andy On Wednesday 09 February 2005 03:39 pm, March, Andres wrote: Can't all the ACL filtering be done when initially loading the object from the Session/Cache/DB but before the object is part of a transaction? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Depue Sent: Wednesday, February 09, 2005 3:23 PM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] PostInvocation and Hibernate Sessions We developed our current ACL type system before Acegi had its ACL system, and planned for this behavior from the beginning (we work with Hibernate as well). Our system has these abilities: 1. Property level ACLs. If the user does not have read access for a property, then somehow blank it out so that sensitive data is not transmitted on the wire. If the user does not have write access to a property and the client attempts to change a value on the property, then throw a security exception when they attempt to persist the object. 2. Instance level ACLs. If the user does not have read access to an instance, then filter that instance out: a. If the instance is the return value of a service method, throw access denied exception. b. If the instance appears in a collection, remove it from the collection. c. If the instance appears as the value of a property, secure the property (via the same process used in #1). Apply these symantecs to all returned objects wherever they appear in an object graph, which, of course, implies recursion. Now consider the typical usage pattern for our rich client application: 1. Rich client makes remote invocation to server side service via service interface. The interface is a proxy that calls the remote service via HttpInvoker. 2. Enter server side: a. We first encounter the general security proxy that does basic role based security checks against the service method itself. b. Next, we encounter the transaction proxy which establishes a transaction context for the remainder of the method invocation. c. Invoke the actual service method. d. Service method returns object graph. e. Leave transaction proxy, meaning the transaction is committed (or rolled back in case of error/exception). f. If there was no error or exception, then we return back to the security proxy which now performs ACL security on the returned graph (note that this is outside of the transaction). The object graph may be mutated during this securing phase. As you can imagine, this gets real complicated when using POJOs and Hibernate (and your Hibernate model doubles as your DTOs), which is exactly what we use. If you retrieve an object graph from one service method, make modifications, and then persist those changes via another service method invocation you are dealing with two totally separate transactions and Hibernate Sessions. The ACL mechanism performs actual modifications to the POJOs in order to secure them, but you do not want these modifications persisted back to the DB as they were temporary and specific to the purpose of securing transmission of data. This is about when you start longing for the more dynamic nature of some other languages - it would be so much easier if I could set dynamic metadata against a property (a property property), or remove a property altogether. Anyway, you somehow have to merge the allowable mutations made by the client with the original object state before persisting to Hibernate. The version of Hibernate we use ( 3.0) does not make this any easier, though it is possible. There are a lot of various interactions that can bite you if you aren't very careful with your implementation. I don't have time now to elaborate on how we solved these various issues. For now, I'll say that we used a combination of AOP, Hibernate Interceptor, and special secured placeholders for objects. The solution is not optimal at the moment. Our version of Hibernate just does not provide any easy way to optimize things, so we end up reading each and every object from the DB before updating it. This means at the time of update we have two copies of each object: the one passed in from the client (which is mutilated, so to speak, because of the ACL mods), and one we just reloaded from the DB via Hibernate. We end up applying
