Les, 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.
That doesn't seem like a good approach for us because we need to support hundreds of thousands of simultaneous sessions across several (say 5-10) different applications and many (say 100) servers. It seems crazy to have every one of those applications store session information in memory, and to have to integrate TerraCotta or another of these tools into all these applications. It seems to be a lot more practical to simply intercept every request to every application, send it to a central authentication server, and then send the user back to his requested URL after he's done authenticating. And of course just send him to his URL immediately if he's already authenticated. This way, individual applications need no real changes - no need to integrate with TerraCotta or other tool, and only a simple XML-configuration to invoke the centralized authentication. Does this make sense to you? Wouldn't anybody who needs to support 100,000+ simultaneous single-sign-on sessions want to avoid storing session info in memory across all the applications? So it seems like my best option to do centralized authentiation with Shiro is to implement my own subclass of Cache that sends a message to the authentication server rather than checking local memory. I suppose I could do that, but it seems like it's a pretty common scenario, so I thought Shiro might have that ability built-in. It seems like maybe I should just use CAS instead of Shiro. It looks like making the Tomcat "single sign on" feature work across multiple tomcat instances (http://www.simongbrown.com/blog/2004/11/04/1099588633312.html) might also be a reasonable approach. Thanks again for all the help. Andy -----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. >
