Hi Les, Thanks for the reply.
With help from a sharp eyed colleague, I finally managed to get this working with a cross-subdomain cookie (by that I mean a cookie with it's path set to root - see below. Is that correct/recommended?) AND a simple implementation of SessionDAO (that stored sessions to a common disk file). I think the best of these approaches also includes using Ehcache to decrease the number of calls into the SessionDAO implementation. I have the above example coded up here: https://github.com/bhamail/shiro-test-dan.git See the branch: minimalSSOWithCache The key tidbits were the SSOcookie path and a simple SessionDAO impl. Here's the related shiro.ini parts: [main] # Use the configured native session manager: sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager securityManager.sessionManager = $sessionManager # the following call is only necessary in a web-configured ShiroFilter (otherwise # a native session manager is already enabled): securityManager.sessionMode = native # session backing sessionDAO = com.danrollo.cache.MySessionDAOToDisk securityManager.sessionManager.sessionDAO = $sessionDAO cacheManager = org.apache.shiro.cache.ehcache.EhCacheManager securityManager.cacheManager = $cacheManager # cookie for single sign on cookie = org.apache.shiro.web.servlet.SimpleCookie cookie.name = SSOcookie cookie.path = / securityManager.sessionManager.sessionIdCookie = $cookie Please comment if you see anything off base in this approach. My plan is to use this approach with a real hibernate SessionDAO implementation to enable SSO across webapps on a single tomcat instance. I think it would be useful to somehow document this sort of simple SSO proof of concept. I'd be happy to try to write something up to be added to the docs. Of course my first question is where would it make sense to doc such a thing? Would some kind of simple project like the one I reference above be worth including as well? Dan On 08/21/2012 01:18 PM, Les Hazlewood-2 [via Shiro User] wrote: > You transfer the session ID's however you want. Many people use > cross-subdomain cookies (with the HttpOnly flag) and reference the > same sessionIdCookie in Shiro's configuration. > > You can also send the sessionID (maybe encrypted) as a query parameter > from App 1 to App 2, e.g. App 1 issues a redirect for > https://app2Host/whatever?JSESSIONID=sessionID > > Although, the 2nd example isn't nearly as secure since the sessionId > is exposed to the end-user. > > HTH, > > -- > Les Hazlewood | @lhazlewood > CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 > Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk > > > On Tue, Aug 14, 2012 at 4:31 PM, bhamail <[hidden email] > </user/SendEmail.jtp?type=node&node=7577714&i=0>> wrote: > > > 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. > > > > > > > > > > -- > > View this message in context: > http://shiro-user.582556.n2.nabble.com/SSO-on-single-tomcat-container-tp7577698p7577699.html > > Sent from the Shiro User mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://shiro-user.582556.n2.nabble.com/SSO-on-single-tomcat-container-tp7577698p7577714.html > > > To unsubscribe from SSO on single tomcat container, click here > <http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7577698&code=ZGFucm9sbG9AZ21haWwuY29tfDc1Nzc2OTh8LTQ0OTgyNzI4Ng==>. > NAML > <http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > -- View this message in context: http://shiro-user.582556.n2.nabble.com/SSO-on-single-tomcat-container-tp7577698p7577715.html Sent from the Shiro User mailing list archive at Nabble.com.
