> I think I know how you'd solve this with Shiro. You'd use a "federated" > approach where you share memory across machines with a subclass of Cache > that uses Jcache, TerraCotta, Coherence, or some other > cross-machine-memory tool.
Actually, I wasn't thinking of that. Sure, that is one way, but as you point out, obviously not ideal in your situation. My approach would be the following: Lets assume Application A represents the application that actually performs the authentication check. Applications B through <insert letter here> would all have the same Realm implementation used in their Shiro configuration that knows how to execute login requests to application A - these could be REST/Soap/RMI or any other type of remoting protocol to call into Application A, perform the authentication attempt, and then return quietly if successful or throw a proper AuthenticationException if not. This Realm would perform only authentication - no authorization. Then you'd have another Realm in your security manager configuration that performed authorization duties with that application's own data model (Shiro supports as many Realms as you want for your application). This has the added benefit of using the same Realm in all applications and is much less jarring to the user - they can log in on the local site and never feel like they are redirected to an additional site with a different look and feel - much nicer. If you're forced to redirect to an external server, then yes, CAS might be a better solution for now, although I think it should be a top priority of ours to support this scenario out of the box. That is, it would be a shame if Shiro couldn't do what CAS does and more. We've talked about supporting SAML and OpenID and other similar mechanisms to achieve this. All of this being said, if you could have an ideal solution regardless of framework - what would that be? Cheers, Les > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Les Hazlewood > Sent: Tuesday, July 28, 2009 4:37 PM > To: [email protected] > Subject: Re: SSO with centralized authentication > > Hi Andy, > > Authentication state must be known by both servers for either of them > to know if the currently executing user (aka 'Subject') is > authenticated. That is, if you authenticate on one server, how is the > other server supposed to know that the user is authenticated unless > they share that state somehow? > > There are a number of ways to solve your problem - are you looking for > an idea of how I would solve this particular problem with Shiro or are > you stating that you're tied to the mechanism that is in place now > (redirect to another web page on another server then redirect back) > and would like to know how to make that work? > > Regards, > > Les > > On Tue, Jul 28, 2009 at 3:20 PM, Andy Tripp<[email protected]> > wrote: >> Les, >> >> We're trying to do a centralized authentication service, in which one >> machine (one tomcat instance) does authentication and all other > machines >> just redirect all servlet requests to the authentication machine. If a >> user is not authenticated, he gets the login screen, and on successful >> login, gets routed from the authentication server back to the URL that >> he requested on the application machine. So we'd have each application >> do what the sample webapp does: have a ShiroFilter in web.xml which >> redirects all URLS to login.jsp. At that point, the >> WebUtils.saveRequest() call saves a URL, but it saves it on the >> application machine, not the authentication server. Then, the > login.jsp >> ACTION is to invoke a servlet on the authentication machine, where the >> WebUtils.getSavedRequest() would NOT retrieve the saved URL, because > it >> was saved back on the application machine. >> >> So it looks like these PassThruAuthenticationFilter and >> FormAuthenticationFilter filters don't support centralized >> authentication out-of-the-box. Everything works for me now, but only >> because I'm running everything on a single machine. >> >> Does all that make sense? If so, don't we need to be "saving" the URL > by >> storing it as a hidden field on login.jsp, and setting the >> user-requested URL as we send the user to login.jsp? >> >> Thanks again, >> Andy >> >> p.s. I'm working with Gurpreet, and this is a variation on her recent >> post to the list. >> >
