shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Turner <incomm...@hotmail.com>
Subject RE: how to realize multi threaded single sign-on
Date Wed, 27 Oct 2010 20:37:35 GMT

Rich,
I'm sure Les will respond with a much more detailed and correct response than this, but I
thought I'd offer a few insights based on a previous implementation. In another life, I worked
with Les on a project which used GigaSpaces, and we managed all of our session data in GigaSpaces.
GigaSpaces was the system of record, for that project--no session data was ever stored in
a database. Because GigaSpaces' spaces are separate entities (or can be) from the application,
it was possible in our environment to do any necessary system maintenance without shutting
down the spaces.
In that environment, we did not use CacheSessionDAO. Instead, we built a GigaSpacesSessionDAO
that implemented the QueryableSessionDAO interface (and, by extension, SessionDAO as well)
directly. That DAO was injected with a GigaSpace object. We had an annotated @SpaceClass(persist
= true) GigaSpacesSimpleSession that extended from Shiro's built-in SimpleSession class and
added annotations as necessary. Our GigaSpacesSessionDAO read and wrote instances of our GigaSpacesSimpleSession
from the cache, and we used GigaSpaces' SQLQuery support to simplify building the various
queries that the DAO implementation required. We did not store the Subject itself in the database
at any level, because it didn't have any important data associated with it. In our GigaSpacesSimpleSession
class we stored the principal for the Subject, which, in our system, was the database primary
key for a User object which contained all the user's pertinent data. The final piece of this
puzzle was a GigaSpacesSessionFactory, which implemented the Shiro SessionFactory interface
and was injected into the DefaultSessionManager to instantiate our GigaSpacesSimpleSession
object instead of Shiro's standard SimpleSession class. This way, our DAO could simply cast
the provided Session (interface) to GigaSpacesSimpleSession as necessary for its operations.
Again, I'm sure Les will be able to expound on this (or maybe even suggest a newer, better
way based on his much deeper understanding of the current state of Shiro and things he's learned
since he and I wrote that implementation.
Hope this helps,Bryan Turner

> Date: Wed, 27 Oct 2010 13:09:41 -0700
> From: rchristy@skyroadasp.com
> To: user@shiro.apache.org
> Subject: Re: how to realize multi threaded single sign-on
> 
> 
> Also looking at the implementation that is provided for EhCache, it looks
> like I will need to implement 3 classes to make this work Cache,
> CacheManager, and a CacheSessionDAO, correct?  Also GigaSpaces make use of
> their own annotations to insert POJOs into their IMDG (In Memory Data Grid). 
> I am assuming I will also have to create a POJO that contains a "Subject"
> instance in order to insert this into their cache implementation.  Am I at
> least on the right track from a shiro point of view.
> 
> thanks,
> 
> Rich
> -- 
> View this message in context: http://shiro-user.582556.n2.nabble.com/how-to-realize-multi-threaded-single-sign-on-tp5204196p5680123.html
> Sent from the Shiro User mailing list archive at Nabble.com.
 		 	   		  
Mime
View raw message