Hi Dan, Shiro only currently directly supports SSO via what I call "poor man's Single Sign On":
Each of your Shiro-enabled applications all point to a shared (networked, distributed) data store (e.g. Cache) and you configure Shiro's native session management using the EnterpriseCacheSessionDao. This means that a session created in App 1 will be able to see/reference/use sessions created in App 2. Because Shiro stores authentication identity/state in the Session after login by default***, if you share the session IDs across apps (e.g. via a cross-subdomain cookie or even via RMI or messaging, e.g. AMQP or JMS), then you can acquire a session from any of these apps based on the session ID: if you're logged in to App 1, App 2 can see your session and consider you logged in as well. This technique requires a networked distributed data store (like Memcache, Terracotta, Coherence or GigaSpaces or Cassandra or ZooKeeper, etc, etc). If this isn't sufficient, you'll need to use a central authentication server like Stormpath or CAS. HTH! *** This is the default. Shiro does not require sessions and this can be turned off for stateless/sessionless applications. -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk On Wed, Aug 15, 2012 at 8:29 AM, Dan Rollo <[email protected]> wrote: > Repost due to forum not forwarding to mailing list: > > > I'm new to Shiro, and trying to setup a simple example of SingleSignOn in > one tomcat container across multiple web apps (without resorting to > terracota). > > I can't figure out how to make the web apps share the login/session info. > > I configured the ehcache for caching, and it appears both web apps are using > ehcache for session info, and only one 'shiro-activeSessionCache.data' file > is created in the tomcat temp folder. > > Also tried using my own EhCacheManager subclass, but not surprisingly the > behavior is unchanged. > > > A small test project is on github here: > [email protected]:bhamail/shiro-test-dan.git > > > I found the following post: > http://shiro-user.582556.n2.nabble.com/Shiro-and-multiple-wars-within-the-same-Servlet-Container-td5560737.html#a5563334 > but it seems it should be easier to setup session info sharing across web > apps in a single container. > > Is using LDAP or Database as a SSO backing store easier? > > Thanks, and apologies in advance for missed obviousness. > Dan > > > > > > bhamail Reply | Threaded | More > Aug 14, 2012; 7:31pm Re: SSO on single tomcat container > > 2 posts > Some more info (and questions): > > In my simple two web app example, I noticed each webapp is always using a > different JSESSIONID cookie value. > > So I'm wondering how Shiro would be able to re-use any subject info across > the sessions of two different web apps? (Are the session cookies supposed to > be different for SSO across web apps?) > > I'm debugging my example case (and even created my own Cache: public class > MyCrudeCacheImpl implements Cache...using a disk based hashtable). I still > don't see how the sessions in the different web apps would ever be linked > up, given they always have different sessionIds. Can you give me some > pointers on how this plumbing between the sessions is supposed to work? > (Does Shiro look into the separate session objects and examine something > there? If so, what?). Once I understand how these should link, maybe I can > figure out what I'm missing.
