f a v's approach is a good one. Shiro's SecurityManager is mostly intended to be an application singleton - i.e. one instance per application.
However, it is possible to set the SecurityManager as a VM-wide (container-wide) static singleton via SecurityUtils.setSecurityManager. This is almost exclusively used in standalone apps, say, a Swing desktop application, where it is expected to have only one application running on the VM. I suppose one of your apps could set-up/configure the SecurityManager and all of it's constituent components (realms, CacheManager, DAO's, etc) and then it could be shared across applications by calling SecurityUtils.getSecurityManager(). However, I've never tested this approach, and I personally feel it might be a brittle solution. f a v's approach of having each app have its own SecurityManager and sharing a cache is a 'cleaner' approach in my opinion. It allows each app to configure their own settings, their own URL policies (if they're web apps), and whatever else they want. The shared cache approach with Ehcache + the cookie settings f a v showed will get you single sign-on for apps hosted on the same machine, which will work well. If you want to use this technique for SSO across applications hosted on multiple machines, only then would you need to use a distributed cache like Terracotta. Mike - does this address your original question? Les On Thu, Sep 23, 2010 at 7:44 AM, f a v <[email protected]> wrote: > If it helps as an example, I've used ehcache and this configuration. > > shiro.ini: > > # Cache for single sign on > ssoCacheManager = org.apache.shiro.cache.ehcache.EhCacheManager > ssoCacheManager.cacheManagerConfigFile = classpath:ehcache.xml > securityManager.cacheManager = $ssoCacheManager > > # native for single sign on > securityManager.sessionMode = native > > # DAO for single sign on > sessionDAO = org.apache.shiro.session.mgt.eis.EnterpriseCacheSessionDAO > securityManager.sessionManager.sessionDAO = $sessionDAO > > # cookie for single sign on > cookie = org.apache.shiro.web.servlet.SimpleCookie > cookie.name = SSOcookie > cookie.path = / > securityManager.sessionManager.sessionIdCookie = $cookie > > # etc... > > ehcache.xml: > > <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="true" > monitoring="autodetect" dynamicConfig="true"> > > <diskStore path="java.io.tmpdir" /> > > <cacheManagerPeerProviderFactory > > class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" > properties="peerDiscovery=automatic, > multicastGroupAddress=230.0.0.1, > multicastGroupPort=4446, timeToLive=1" > propertySeparator="," /> > > <cacheManagerPeerListenerFactory > > class="net.sf.ehcache.distribution.RMICacheManagerPeerListenerFactory" /> > > <cache name="shiro-activeSessionCache" maxElementsInMemory="600" > eternal="true" overflowToDisk="true" > memoryStoreEvictionPolicy="LFU"> > <cacheEventListenerFactory > > class="net.sf.ehcache.distribution.RMICacheReplicatorFactory" /> > </cache> > > <defaultCache maxElementsInMemory="100" eternal="true" > overflowToDisk="true" memoryStoreEvictionPolicy="LFU"> > </defaultCache> > </ehcache> > On Thu, Sep 23, 2010 at 11:09 AM, slott > <[email protected]> wrote: >> >> I guess you are asking this to achieve SSO between your webapps running on >> the same Tomcat (Jetty etc). >> >> I have been wondering about the same thing, and find the suggestions on this >> forum about using Terracotta or similar enterprise distributed caches to be >> quite an overkill for this situation. >> >> After my 5 min research into the issue, there does not immediately seem like >> you can share the shiro native session between apps on a single web >> container out of the box. >> >> But perhaps it is possible (and easier) to share such resources using Redis >> or Memcached,... etc? >
