Thanks again for the feedback, Les. My responses are below. Andy > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Les Hazlewood > Sent: Tuesday, July 28, 2009 6:46 PM > To: [email protected] > Subject: Re: SSO with centralized authentication > > > 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.
That sounds good, except that application B would call A, passing the URL and saying "the user wants to get to this URL. If he's authenticated, just send him there. If not, give him a login window and once he logs in successfully, send him there." There's no need for B to throw an exception - B sends the message to A and is then done. > 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). OK. > > 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. OK. > > If you're forced to redirect to an external server, We're not really "forced" to do it that way, it's just that I prefer having authentication handled by an external server to free up all my company's web applications from having to deal with it (though I've now changed my mind on this - see below). > 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? My only real requirements are to have single sign-on across multiple web apps supporting many (100,000+) simultaneous user sessions. In the short term, we have to use an existing database of username/password entries. Long term, we'll want to change that to use something more standard like LDAP. We can expect that we'll soon want to support authorization in addition to authentication. Ideally, I'd like to have a simple configuration file on each application machine that says "Everyone who accesses any URL here first has to go through authentication". As I mentioned above, the only real requirement for the authentication machine is that it accesses an existing database for now, and probably uses LDAP later. So a good solution would be Shiro running as a servlet with our own JDBCRealm today and maybe an ApacheDirectoryServerRealm later. The Tomcat Single Sign On feature looks good, but it only works within a single Host and also I doubt that we can dictate that every web app in the company must use Tomcat. Switching gears now... I'm now thinking that we really should do a "federated" approach, such as using Terracotta. My objection to this was that having individual applications all sharing session data in memory was a huge waste of memory. But it turns out that Terracotta only keeps "local session data" in memory. In other words, each machine really does only keep the session data that it really needs in memory, not ALL session data. When it needs session data that's not "local", it gets it from a centralized server. Architecturally, Terracotta looks like essentially an already-built version of the "centralized" approach. We've been talking about me writing a Shiro CentralizedAuthenticationRealm that always sends a message to an authentication server. Well, that's what Terracotta already does, it's just that it keeps local session data in a local cache so that it doesn't always have to hit the authentication server. There are several advantages of using Terracotta (or similar tool): 1) We can start using authorization without a lot of work - the shared session state would contain authorization info in addtion to authentication info. With my own hand-coded Shiro CentralizedAuthenticationRealm, I'd have to do extra work to get authorization info. 2) We get other shared session info, such as a "shopping cart", "for free". With a Shiro CentralizedAuthenticationRealm, I'd have to build this functionality. Having such a "shopping cart" is not a requirement for me yet, but I can certainly see it coming down the road. We have telephony applications, and one webapp might start a conference call while another starts a normal call. The "normal call" web service would want to know that you're already in the midst of a conference call that you initiated via the "conference call" web service. 3) Load balancing - say we are using some load balancing scheme where you make a request from a web service, and then when you make a second request to that same service, a load balancer redirects you to a different server. Those two servers should share your session info. I'm now investigating Terracotta Web Sessions. The question is "do I need Shiro on top of it?" I suspect the answer is "no, unless you're doing something 'custom', Shiro doesn't help you". So now after looking into it a bit, I'm starting to see why is seems that most large apps seem to be using things like Terracotta and Coherence rather than CAS. I have two specific suggestions for Shiro: 1) Go ahead and build a TerracottaRealm class and let me use it via ShiroFilter configuration in web.xml. 2) Create a lot more and better documentation. For example, I should be able to get an authentication server and a couple of application servers up and running in under an hour. Take a look at the Terracotta Web Sessions tutorial, for example: http://www.terracotta.org/web/display/orgsite/Sessions+Tutorial Following that, I was able to get two "Jpetstore" web apps running and sharing sessions within about 20 minutes. The shiro QuickStart application is pretty good. Create a similar writeup for the 'webapp' version of it. Thanks again for your time. Sorry for the long email. Andy > > 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. > >> > >
