Thanks for pointing me in the right direction. I am sure I will have more questions as I start to figure this architecture out.
On Fri, Aug 28, 2009 at 6:46 AM, Les Hazlewood-2 (via Nabble) < [email protected]<ml-user%[email protected]> > wrote: > I might be able to expand on this more when I have some time later > today or tomorrow, but you're in luck - the latest commits to SVN > trunk this week are providing support for what you should need. > > Look at the Subject interface and the new associateWith methods - you > can dispatch the return values of those calls to an ExecutorService or > thread pool if necessary and the Subject data will be retained on > those other threads. > > As far as remoting support, you'll need to copy what the ShiroFilter > does in its bind method: > > - create a subject instance with the security manager based on > contextual data (using a Subject.Builder instance - that is still > being worked on today) > - bind that subject instance and its associated state to the thread. > I created a ThreadState interface that abstracts the actual work away > - call whatever you want, such as a filter chain, or AOP method > interceptor chain, or a target method > - always unbind the thread state in a finally block to ensure the > thread can be reused in a pooled environment. > > You can look at the ShiroFilter's source code to see how it goes about > doing this - it all starts in the doFilterInternal implementation. > You would just need to recreate this logic in the component that first > receives the inbound remote invocation/request. > > Note that this logic and its utility classes are still in flux and I'm > refining them today and tomorrow, and if you'd like to follow along, > please join the dev list. > > HTH, > > Les > > On Tue, Aug 25, 2009 at 4:24 PM, brianga<[hidden > email]<http://n2.nabble.com/user/SendEmail.jtp?type=node&node=3534753&i=0>> > wrote: > > > > Hi... > > > > I was hoping someone here could give me some advice on the best way to > > integrate shiro into our application. > > > > We have a server-based app that is exposed via JMX using an RMI > transport. I > > just recently replaced the JAAS based authentication with a shiro based > one. > > Our app runs in a Spring container and so I used that to instantiate the > > security realm and the security manager and then have a hack in the code > to > > set the security manager using SecurityUtils. This was just a proof of > > concept move and have gotten authentication working fine. > > > > Now I am moving on to authorization, but initially need to deal with how > to > > manage the subjects so that any calling code can call getSubject and get > the > > correct subject back. Since the calling code needs to just be able to > make > > the call blindly I think the subject needs to be on the ThreadContext, so > > > the question is how to get it there. > > > > In looking at it, it looks like I may need to derive from RMIServer and > > RMIConnection classes. The first being necessary so that I can put an > > authenticated subject in a manager mapped with some connection id or > > something. The second being necessary so that I can intercept a call > coming > > in and retrieve the subject from my manager and place it on the thread > > context. > > > > Does this seem like the correct approach? Is there any examples of > something > > like this? > > > > Any advice or info would be appreciated. Thanks... > > -- > > View this message in context: > http://n2.nabble.com/Best-approach-for-integrating-shiro-tp3512431p3512431.html > > Sent from the Shiro User mailing list archive at Nabble.com. > > > > > ------------------------------ > View message @ > http://n2.nabble.com/Best-approach-for-integrating-shiro-tp3512431p3534753.html > To unsubscribe from Best approach for integrating shiro?, click here< (link > removed) =>. > > > -- View this message in context: http://n2.nabble.com/Best-approach-for-integrating-shiro-tp3512431p3536974.html Sent from the Shiro User mailing list archive at Nabble.com.
