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 >
