Actually, looking at f a v's ehcache.xml, you don't even need terracotta if you don't want to use it - apparently it's using Ehcache's built-in distributed clustering mechanism. I don't know if this 'hooks in' to TerraCotta or not though. Very cool.
Les On Thu, Sep 23, 2010 at 12:11 PM, Les Hazlewood <[email protected]> wrote: > 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? >> >
