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
