I just created https://issues.apache.org/jira/browse/SHIRO-385 and added some simple example classes there... not compiling, but enough to get you started
On Tue, Aug 21, 2012 at 1:59 PM, Ryan McKinley <[email protected]> wrote: > If you are running on Windows and want to use Negotiate/NTLM to get > the currently logged in user, take a look at WAFFLE: > http://dblock.github.com/waffle/ > > It is a remarkably easy integration with windows authentication via JNA. > > I have a trivial AuthenticatingRealm that uses Waffle for > username/password tokens to login. The difficult thing is supporting > Negotiate. I have a hacked up AbstractShiroFilter that handles > Negotiate/NTLM/Basic *if* the Authorization header is included in the > request. I can share that if you like, but it has a bunch of internal > things and would take some cleanup to make generally useful. > > ryan > > > > On Tue, Aug 21, 2012 at 9:22 AM, Les Hazlewood <[email protected]> wrote: >> 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.
