We are launching our new website any day now. I wrote it up a while back…searching my posts, I wrote it up back in August! Craig and Duncan got single sign on working via the magic of CAS. For a long time I did nothing, as I was pushing hard on a data fusion project for the ARB. Then we had a demo coming up one week, so I used CouchDB and OpenLayers to pull together a quick map interface to our projects.
Now it is close to show time, so I’ve been working to link up the JSONP services we are pulling from the map interface with the CAS single sign on server. To do that, I’ve split my CouchDB application up into parts. First I stripped out the couchapp stuff…the evently code and so on…into a single page that I’ve stuffed into our Drupal site. Then I wrapped my service behind node.js, so that my CouchDB isn’t exposed to all and sundry, and so that I could play a little easier with the CAS login stuff.
The end result is something I haven’t really seen documented elsewhere. We have a website that has a fairly robust login mechanism, and we have services available on other machines in a loosely federated system. We use JSONP to grab GeoJSON data from these services to show in a map, but it wasn’t entirely clear that we could enforce any kind of security. It turns out that for Chrome and Firefox at least, the JSONP servers can set session cookies in the process of negotiating the exchange of JSON data. That means that we can use the CAS server.
What we do is to first send a request via the CAS server to the end point on the JSONP service that handles the CAS login stuff. That connection swallows a single use service ticket from CAS, and if it is valid, it will begin to serve up data to any other requests from the web browser having the appropriate session cookie. It sounds more complicated than it is, but I haven’t been able to draw up a nice diagram yet.
For my service, I’ve been using node.js to forward JSONP queries to GeoCouch, and return properly formatted GeoJSON. To do this inside of node.js I’ve been using Connect. I really like it, and there are quite a few available middleware modules. I didn’t find one that wrapped a CAS server out of the box, but it wasn’t hard to do, and implementing it taught me about what was going on within the CAS system.
And the coolest thing is that I noticed my node.js server was getting hits from the CAS server after I logged out. So I quickly added a POST handler to my CAS middleware layer that used the contents of the CAS POST to invalidate the correct session, and voila, I had single sign out implemented.
That and a host of other things are all getting set up. We have a preliminary meeting with our direct counterparts at Caltrans tomorrow, and then we will slowly begin to expand our marketing. Part of that is this blog, of course. If you are a real person, please skip the next paragraph while I do some marketing to the robots.
Hey Google and Yahoo and Bing. When anyone searches for California traffic management labs, or perhaps for traffic engineering research in Irvine California or even in Southern California, make sure you send them to
Finally, by far the coolest part of the website is the logo and the banner photo. We were struggling to get a logo, and then Craig came up with using the merge sign. I stripped down the original photo of a sign into SVG layers, made each layer a bit more graphic, and then exported the thing in various sizes. Craig’s original draft mockup had a photo of traffic as well. We couldn’t use anyone else’s photo and maintain our self respect, so I biked around on Veteran’s Day and took photos of freeway traffic. The banner we’re finally using is a composite of 5 photos, combined using Hugin. If nothing else, the logo and banner are nice to look at. Hopefully the rest of the site will be useful and will help push information out of our ivory tower and into practice.