On Thu, 2006-10-19 at 17:05 +0200, Ingo Siebert wrote: > Hi Ray, > > thank you for your answer. > I thought i should use ACEGI for every thing i can, because it's hard in > my eyes to build a "instance based security system" which is secure and > fast. > That's why i wanted to use the ACL/ACE feature. > > But i like your answer to solve that by a query, because it's sounds > logical. But it also means i have to do all myself and if i do all > myself, i'll do every fault possible (=> murphy's laws). :( > > It would be interesting for me to know, what's the main points to keep > such a system fast. > The problem is, that it is very expansive to check for every "contact" > instance (for example) the permissions, because there are some users and > hierarchical groups(with associated users) and maybe inherited > permissions from parent classes. > It seems impossible to do such things in fast way... > > I would welcome every answer to my question, but i don't think that you > are totally wrong. It's always good to hear more than one opinion. :) > Actually, you may be able to have your cake and it eat it too. I have the same business case as you. My first cut was to implement some after-advice interceptor to filter out the result set. Of course, that turned out to be quite expensive.
I have since replaced that with a utilization of the ContextPropagatingRemoteInvocationFactory in order to propagate my security contexts over to the remote server side methods. (http://www.acegisecurity.org/multiproject/acegi-security/apidocs/org/acegisecurity/context/rmi/ContextPropagatingRemoteInvocationFactory.html) There is a thread on Spring forums that discusses discusses this (in this case RMI, http://forum.springframework.org/showthread.php?t=27947&highlight=ContextPropagatingRemoteInvocationFactory) This lets you get the SecurityContextHolder passed through to your server method, and you can tap into the user's credential data to extract the filter criteria you need to refine the WHERE clauses of your query. Assuming the server side SecurityContextHolder is configured with a ThreadLocal strategy, this is thread safe, and don't have to change any method signatures. My users happen to have one common filter criteria that isn't tied to credential data. Instead, the users can pick from a set of radio buttons spread across many GUI screens, some canned filters to look at a subset of data. While not security related, it was part of the user's "context" of operating. So instead of updating a dozen different method signatures, I just subclassed SecurityContext as MyFilteredSecurityContext, and added this extra filter as an attribute. Anytime they click on the radio buttons, I update that piece of their context. Next, whenever they go to the database for new information, the context is sent a la AOP to the server, and the server plucks this filter criteria out of their SecurityContext, creating a dynamic adjustment to the query. Like I said, have your cake and eat it too. Greg ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
