SSL and authentication across multiple domains

Question

I am building an app with Ruby on Rails which allows users to sign up and create their own subdomain:

joebloggs.myapp.com

So at the very least I need a wildcard SSL certificate to handle when users are passing sensitive data (authentication, payment etc).

In addition, we are allowing users who want to, to map their own domain to their account, like:

www.joebloggs.com

Which all of a sudden creates a massive headache. I'm assuming no SSL product exists to serve this purpose (ie, potentially be used over unlimited domains)?

The app is essentially a CMS, so it has a public facing website, and a admin back end. It is essential that the public facing website side of things has the facility to be mapped to the user's domain. However, I'm less concerned about the admin area and would quite happily force users to log in and administer their site via their subdomain.

However, whilst for the majority of the website it does't really matter whether the user is logged in or not, I DO want to be able to know whether the user is logged in so I can serve up slightly different content to logged in users. I'm assuming this is going to cause me a problem because the cookie can't be used over multiple domains (or can it?). I'm using Authlogic for authentication.

So really, I'm just wondering if anyone has come across a situation like this before? If so, what approach have you taken to get round the several issues here?

Answer 1

This may not be an answer to your problems. But your question has gone 6 hours without an answer, so I thought I'd pitch in with a couple of alternative ideas. Perhaps it will spur some creativity in other readers' minds. :)

These are sorted in the order of how neat a solution I personally think they are.

Always have a subdomain, even if the user has his/her own

Following your example, you could serve exclusively static pages on www.joebloggs.com, with login links that link to joebloggs.myapp.com. If a user is already logged in, the actual login step can be skipped because cookies are then available.

This would require all users to have a subdomain, even if they specify their own domain.

Serve static pages, and use cross-site AJAX

There's a relatively new draft standard called Cross-Origin Resource Sharing, which allows AJAX requests across domains. Firefox supports it as of version 3.5, and there are some more readable (than a W3 spec) examples of how this works in practice over at the Mozilla Developer Center.

Besides Firefox 3.5, this appears supported in IE 8. It's in newer versions of Chrome and Safari, but I can't pinpoint since which version. (Webkit changeset #41046.) I can't find anything definitive about Opera.

Also note that non-GET requests have the extra overhead of a 'pre-flight' request.

Serve dynamic parts with an iframe

Iframes can be well hidden with some CSS, and made to appear seamlessly on the page. You could serve up the dynamic parts of your page using iframes that point to myapp.com. This would work reasonably well if the dynamic part is just a slice of the page header with some account info and links, for example.

If you plan on hiding content based on the user's privileges, you could take this as far as serving the entire content area of the page as an iframe.

Downside is that some browsers might complain about mixed plain and secured content.

The classic hide-behind-an-invisible-frame trick

Lots of sites that used to be hosted on platforms such as Geocities used to have those free .tk domains that 'hide' the site behind the pretty URL in the address bar. The trick was that the .tk domain served a frame-set with an invisible frame, and another frame covering all of the window, which would serve the Geocities site.

This is ugly, of course, but I had to mention it. It means that the address bar will not update with link navigation on your site, and will always show the root URL. It also neglects a lot of possible advantages for having a separate domain. And it may even have the same downside as the previous trick with iframes.