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.
