You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by bhamail <da...@gmail.com> on 2012/08/15 01:31:34 UTC
Re: SSO on single tomcat container
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.
Re: SSO on single tomcat container
Posted by bhamail <da...@gmail.com>.
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.
Re: SSO on single tomcat container
Posted by Les Hazlewood <lh...@apache.org>.
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 <da...@gmail.com> 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.