Hi Andy, Please see my comments inline.
On Mon, Aug 17, 2009 at 12:04 PM, Andy Tripp<[email protected]> wrote: > Hi Les, > > After spending time with Terracotta, I'm back to trying to just use > Shiro to implement SSO across multiple applications. I want to do what > you suggested...Each application will keep session info for that > particular application locally, and there will also be a centralized > machine containing session info for ALL applications. When a user logs > in to one app and then jumps to another app, he shouldn't have to login > again. In that case, Shiro can't find session info locally and should go > look on the central machine. Yep, this will work fine. Typically most enterprise caches can do this for you automatically - they have a concept of a 'local' cache - something that is an in-memory '1st level' cache that transparently sits between your application code and the 'main' cluster-wide cache. Try to leverage that if possible to make your life easier. > > I have Shiro working on a single machine now: > * in web.xml I have: > [main] > realmA = com.vonage.auth.client.VonageAuthenticationRealm > > [filters] > authc = > com.vonage.auth.client.VonageFormAuthenticationFilter > > My VonageAuthenticationRealm class extends JdbcRealm and connects via > JDBC to our machine that has username/password info. The > VonageFormAuthenticationFilter class just overrides onLoginFailure() to > give the user an error message and overrides onLoginSuccess() to send > the user on to the URL he requested. > > So that's working fine and now I want to: > 1) send session info to central server on successful login Note that a session may be started before someone logs in (apps differ, but this is often the case). That is, if a user visits the home page and starts browsing around, often a session is created reflecting this activity. Then, after they log in, only then is their identity associated with the session. You probably have to account for this in your app (unless the only time a session is created is actually when they only successfully log in the first time, but most apps don't work like this) > 2) have Shiro check the central server when it can't find a given user's > session info. Again, check your caching product to see if this can happen automatically. You'll be much happier :) > I see in the ShiroFilter javadoc, that I should do this to use "Shiro's > Session infrastructure" rather than HttpSession: > securityManager.sessionMode = shiro This is probably a typo that hasn't been fixed yet. Originally the sessionMode was the name of the framework. Now that token has been changed to 'native' so we should never see naming conflicts again. If you're using the latest build of Shiro (Maven snapshot, or building from source) - and I highly recommend that you do since there has been some necessary fixes for distributed sessions - you'll want to set that to: securityManager.sessionMode = native > I should do that, right? And then what? Where is Shiro checking for > session info, and how can I tap into that? Once this is set, you'll want to write a org.apache.shiro.session.mgt.eis.SessionDAO implementation that interfaces with your cache on behalf of Shiro. However, if you're using an enterprise cache like Terracotta, a better solution is to write Terracotta-specific org.apache.shiro.cache.CacheManager and org.apache.shiro.cache.Cache implementations. Then you can use the org.apache.shiro.session.mgt.eis.MemorySessionDAO implementation and inject it with your cache manager. For example: cacheManager = com.mycompany.shiro.cache.TerracottaCacheManager sessionDAO = org.apache.shiro.session.mgt.eis.MemorySessionDAO sessionDAO.cacheManager = $cacheManager securityManager.sessionDAO = $sessionDAO securityManager.cacheManager = $cacheManager Best, Les P.S. I haven't checked Terracotta's open-source license, but if it is Apache/BSD-compliant, and you're willing to contribute your implementations, I'm sure we can discuss about including it in Shiro proper to make your life easier in the future.
