Hi Chris, Don't know much about Event MPM or COMETD/WebSockets, so I can't help you there. We configured the loadbalancers and SSO-gateways so that when Rave communicates with Shindig on a server-to-server basis, they do so by external hostname (not localhost, but the hostname the browser uses also) and the loadbalancers and SSO-gateways make sure the requests end up on the same cluster node the request was issued from, and the right sso-headers are injected. All this is done without SSL, because communication between these machines is on a private LAN.
The failover between cluster nodes is very straight-forward. The SSO-gateway makes sure a user is authenticated again against a new cluster-node, in case a cluster-node fails. So we don't distribute sessions or anything. No JSESSIONID issues so far. I agree that for a basic setup a reverse proxy is not ideal. However, in most cases you will want to set up a redundant / clustered environment so we'll need some kind of loadbalancing mechanism in front of multiple cluster-nodes, which mainly is just a smarter version of a reverse proxy. Doing SSO at the same time, like we do, introduces another proxy (depending on your SSO setup). For a testing or developing environment all this is not needed, but Rave works fine without, but not as secure as you would want a production environment to work. Dennis On 12-10-2012 17:48, Chris Geer wrote: > Jasha & Dennis, > > Thanks for the response. That is exactly what I'm doing today (just using > HTTPD auth instead of Shib). My major concern with the current approach is > we are using COMETD/WebSockets which don't scale well through HTTPD so I > was hoping to replace it with something like nginx but that would require > me to do the authentication at the app server level (I think). I also need > to test the Apache event MPM and see how that performs. The major downside > of the Event MPM is that it doesn't support SSL but I think I can get a > load balancer that will do SSL offloading prior to apache. I believe I > updated the SSO plugin to support Rave 0.14 a while back. I'll give it > another bump here soon. > > Even doing authentication at the proxy isn't 100% ideal because any cross > server calls won't have that special header unless we introduce it > manually. From a Rave perspective we probably need to think about this a > little more since I'm not sure our default answer to security would be "run > behind a reverse proxy". > > How did you guys solve the clustering problem so that users could failover > between Rave instances? Or do you just re-establish the session on each new > box individually? Doesn't that cause an issue with JSESSIONID? > > Thanks, > Chris > > On Fri, Oct 12, 2012 at 8:37 AM, Dennis van der Laan < > [email protected]> wrote: > >> Hi Chris, >> >> Here at the University of Groningen, we're using the setup as Jasha >> describes, in a production environment (currently for about 4500 >> employees and 9000 students and still growing every day). We're using a >> loadbalancer (redundant) to balance over multiple Rave instances (which >> use the same Oracle11 database), through an "SSO-enabled gateway" which >> adds the request headers Jasha mentioned. The loadbalancer filters these >> headers, so nobody 'outside' the loadbalancer -> Rave network can add >> fake headers. >> >> Because Shindig is behind the loadbalancer and SSO-gateway, every host >> connecting to Shindig will have to be authenticated too, as long as you >> configure the SSO-gateway in that way. >> >> The Rave SSO extension Jasha wrote is used by us, but we had to updated >> the code to match Rave 0.12, the version we are currently using. Newer >> versions of Rave might need more work. We are still developing and on a >> tight schedule, but are planning to give back any enhancements we made >> back to the community. >> For the Rave SSO extension you might just use Jasha's version and update >> it to the Rave version you are currently using, or I could send you our >> version. >> >> Best regards, >> Dennis >> >> On 12-10-2012 11:19, Jasha Joachimsthal wrote: >>> Hi Chris, >>> >>> I don't have real production experience, but have done setup of Rave on a >>> server a few times. The Tomcats that contain Rave and Shindig were not >>> directly accessible. The visitor could only access HTTPD, that request >> was >>> proxied via Shibboleth to Tomcat. Shibboleth adds a request header with >> the >>> user name. At the time I wrote the Rave SSO extension [1] to pick up this >>> header in Spring security and provision the user. It's probably a bit >>> outdated since the splitup of the Rave models. Important is that the >> header >>> that is used to for the authentication should be filtered in HTTPD if >>> someone would try to set it manually on the request. >>> In this setup Shindig doesn't check authentication, but you can only >> reach >>> Shindig when you are already logged in. Now there was an issue with the >>> "internal" calls from Rave to Shindig for the metadata. Rave uses a >> single >>> host property for both the Javascript and the "internal" metadata calls >> to >>> Shindig. We allowed traffic from the portal host to Shindig to bypass the >>> authentication in the load balancer. It would be cleaner to have the >> option >>> to set a different host for the metadata calls so the portal can directly >>> access Shindig. >>> >>> [1] http://rave.apache.org/documentation/sso-login.html >>> >>> Jasha >>> >>> On 12 October 2012 00:45, Chris Geer <[email protected]> wrote: >>> >>>> I've been looking at coming up with a good production deployment >> strategy >>>> and was curious if someone had already solved some of the same things >> I've >>>> been running into. >>>> >>>> 1. Shindig allowUnauthenticated: right now Shindig is set to to not >>>> authenticate requests. When I try and set that variable to false >> (tell >>>> Shindig to authenticate requests) every request to a page gives me >> this: >>>> "WARN : org.springframework.web.client.RestTemplate - POST request >> for " >>>> http://localhost:8080/rpc"; resulted in 401 (Unauthorized); invoking >>>> error handler". This issue caused because the Rave server is making a >>>> request directly to the Shindig server (two separate web apps) >>>> in ShindigGadgetMetadataRepository and isn't passing any credentials. >>>> Has >>>> anyone found a way to resolve this? I also suspect that once the >> first >>>> problem is resolved there will be another problem because the browser >>>> (container) will be making requests to Shindig as well which would >> need >>>> to >>>> be authenticated. >>>> 1. Potential Solution #1 - Combine Rave/Shindig into single web >> app >>>> so that once authenticated to Rave you are also authenticated to >>>> Shindig. >>>> 2. Potential Solution #2 - Have Shindig and Rave use the same >>>> authentication technology and share session state between the two >>>> apps. >>>> (Shindig uses Shiro currently kind-of...benefit is shiro has great >>>> distributed session management which can be used for SSO) >>>> 2. High Availability: Does anyone have a good solution to be able to >> use >>>> Rave in a failover scenario? At the very least we need to be able to >>>> share >>>> security session information between Rave nodes so that if a server >> goes >>>> down people don't have to log in again. I suppose the default option >> is >>>> to >>>> use Tomcat replication but it's not my first choice. >>>> 3. SSO: Our solution uses Rave running on Tomcat but then a lot of >> our >>>> gadgets call out directly to web services that we also host running >> on >>>> Apache ServiceMix. I've got a poor mans SSO right now with an Apache >>>> HTTPD >>>> reverse proxy but it's not a great long term solution. My first >> approach >>>> was going to use Apache Shiro but there doesn't seem like there is a >>>> good >>>> way to use Shiro in Rave since it's based on Spring Security. I've >> also >>>> considered using a CAS server for the SSO part but wasn't sure how >> that >>>> would work out. Has anyone done something similar? >>>> >>>> Thanks, >>>> Chris >>>> >> >> -- >> Dennis van der Laan >> >> -- Dennis van der Laan
