Hi Chris, Based on what I have seen, this is a fairly unusual setup - most applications only configure a single SecurityManager instance for the entire app. I think this is because starting up an embedded web server within an application is more complicated than just creating a .war file that runs inside any servlet container (i.e. if you know you have to support web protocols, just create the .war, and if it never happens to accept web requests for a particular product installation/environment, then so be it - it doesn't hurt anything. But it can afford later benefits like a web console for the app, etc. But I digress).
That being said, I don't know your environment requirements or legacy mandates, so I'll try to help the best I can. The crux of this issue (as far as I can tell) is that you need to expose objects created in one part of the application stack to objects in another part of the application stack. The Shiro Factory interface is supposed to expose any lookup logic as might be necessary. One very simple approach that isn't particularly elegant is to use static memory: the part of your app that initializes Shiro SecurityManager 1 can collect the realms and stick it into a collection in static memory. The web app, when creating SecurityManager 2, uses a Factory implementation to look at that known static memory location to get that collection and returns them from the Factory. You might instead want to implement a RealmFactory instead of just Factory, which can return a collection. The thing to keep in mind here is that each SecurityManager has its own internal components - cache manager, SessionManager, etc - a session in one SecurityManager won't be shared in the other SecurityManager unless you enable session sharing via a CacheManager shared by both SecurityManager instances (which implies sharing objects again). I can't speak to your environment, but most applications utilize things like Spring, Guice, JEE CDI, etc. to maintain the in-memory pool of objects and to ensure those objects are accessible to components for configuration as necessary. Barring using one of these mechanisms, it sounds like you'll need to do something similar. Static memory is one example of an approach, but I'm sure there are many other approaches. I should note that the DefaultWebSecurityManager implementation can be used in non-web applications as long as a native WebSessionManager is configured (not using the default Servlet container-based session manager). For non-web cases at runtime, the DefaultWebSecurityManager and DefaultWebSessionManager implementations just delegate to their parent classes for behavior (which has no knowledge of web concepts). You might be able to get away with just configuring a single DefaultWebSecurityManager that is used in both parts of the app. The key would be sharing it with the web tier, which is where the org.apache.shiro.web.env.WebEnvironment (and MutableWebEnvironment) concepts come into play. You could create a custom implementation of that interface to look up your SecurityManager (or Realms, or whatever) from whatever location (and configure that instance in web.xml as described in Shiro's web documentation). The ShiroFilter will consult the WebEnvironment instance to acquire what it needs to filter requests at runtime. Finally, and again, I have no idea if this is plausible for your application, but I would definitely try to build the app as a .war. If you need it to run standalone, Jetty allows you to do things that can start up the app by doing something like java -jar myapp.war and boom - instant web app. Now if your web app never accepts web requests, who cares - at least you still have a cohesive application. Just trying to help! Cheers, Les On Wed, Jan 25, 2012 at 11:08 PM, Chris Richmond <[email protected]> wrote: > I have an application with security manager with a couple of custom > AuthorizingRealm implementations which I am trying desperately to reuse in > my embedded Jetty web application. I have wired up a login auth app with no > problem and it calls a class I specify in my inline shiro .ini section of > web.xml. > > Even in my realms I specified I tried to use > > SecurityUtils.getSecurityMagager and pass on auth information to the > pre-existing realm but this code returns a completely different security > manager (a DefaultWebSecurityManger class) where as calling that code in the > rest of my application, returns a DefaultSecurityManager, so Shiro has > automatically created 2 security managers, one for my Jetty apps and one for > my in memory? > > I cannot figure out how to bridge this gap, allowing the already existing > AuthorizingRealms i've written for the rest of my (non web app) to my > embedded Jetty web applications or even better have one security manager and > realms for my server application and it's embedded Jetty server. It seems > like this would be a common usage scenario and should be easily supported by > Shiro. > > Les has greatly helped me to get my web application secured using my own > specified realm classes for form based auth checks using web.xml/inline > .ini, going to a dummy auth realm class I wrote just to sure it is being > called, > and that is working fine. > > I just need figure out how to bridge the gap now to reuse my already in > memory AuthorizingRealm implementations from my main (non-web) server > application and I am stuck > > Has anyone successfully done this or something close? I have seen plenty of > shared session threads, but that comes later, for now I am simply trying to > share AuthorizingRealms between my DefaultSecurityManager for my main app > and my DefaultWebSecurityManager that gets crated for my embedded Jetty > application. > > Thanks very much... > > Chris
