Hi Greg, thanks for your answer. The first part is a little different for me, because my server has a WebService interface (and Clients are done with Java(Axis),.Net, Groovy, ...).
I'm not quite sure (as you wrote) if it is nice to use a subclassed SecurityContext for such things, but your are right: It's a relatively simple and powerful strategy. I'll test this strategy and see how it looks. Thank you! I'm also still struggling with me of about ThreadLocal, because it's hiding parameters and dependencies. Cheers, Ingo -- CRM Products Development - New Technologies CAS Software AG Well informed. Always and everywhere. www.cas.de gregturn wrote: > 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
