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 > >
