URL Design for SSL-Secured SaaS Application

Question

I am developing an application using the ASP.NET MVC platform, which will be exposed as a service over the web (the SaaS model). I am trying to determine the best way to partition the URL namespace for each user account. The application will need to be accessed securely via SSL, so my main concerns have been around coming up with a URL design that works well with SSL certificates. Here are the options I have come up with. In each example bob and jane are two example user accounts:

Option A: Each Account Has Unique Subdomain under Common Domain Name

e.g.

https://bob.example.com
https://jane.example.com

• This would require a wildcard SSL certificate (e.g. mapped to *.example.com) so each user can seamlessly access their account via SSL. By seamless I mean without the web browser warning the user about SSL certificate problems. The only drawback I can think of is that wildcard certs seem to be considerably more expensive than normal fixed domain certs. The cost difference will certainly be negligible in grand scheme of things, but it is something I am keeping in mind if all else proves to be equal.

Option B: Each Account has Unique Domain Name

e.g.

https://bobs-domain.com
https://domain-of-jane.com

• In this case, each user would have an SSL certificate tied to their domain names. One big drawback I can think of is that our servers would have to maintain the private keys for all the users' certs, and we would have to design a system that allowed users to securely transmit their private keys to our servers. Even if we had such a system, I feel it would be too much of a burden on users to have to acquire a certificate then submit the private keys to us.

• Alternatively, we could automatically issue and provision an SSL certificate for each user when they sign up, so they can start accessing their app via SSL without additional steps. This would require that we become an issuer of SSL certificates, which I haven't looked into yet... likely we would be a reseller for some other big company like Verisign who specializes in this sort of thing.

• Despite the apparent pain of this approach, this option does enable some features that we may want to provide in the future, i.e. allowing user's to have their own branded version of the app accessed via their own company domain name.

Option C: Each Account has Unique Subdirectory under Common Domain Name

e.g.

https://example.com/bob
https://example.com/jane

• From the perspective of SSL certificate maintenance, this is probably the best option. We would only need one fixed domain SSL cert (e.g. example.com) which would be used by all users.

• Unfortunately this URL design does not work well with other aspects of our current application architecture, especially around load balancing.

Need Feedback

My question to you all is: what option would you choose, and why? I would especially love to hear real-world examples and experiences, but any other issues or concerns that I haven't already presented would be appreciated.

Answer 1

I would go with A. This solution is not very expensive, it scales well and it does not limit you to go with custom domains, if you decide this later on.

Wildcard certificates used to be quite expensive, but today you could get them around 200 USD annually at GoDaddy or RapidSSL, which I think is pretty cheap. These certificates works in (almost) any browser, but they doesn't come with the validation, VeriSign provides. I don't know whether you need this.

If you go with option B, you have to purchase a certificate per user, but with a wildcard certificate, the certificate will be paid after a few sign-ups and the rest will be pure revenue.

Aside from this the solution is really simple to implement, which also is a strength.

Answer 2

Sound like option B to me. It's the only one that seems to a) work with your architecture and b) work with your potential future goals. You can make the price of the SSL cert for the custom domains part of the start up cost for the service (or amortize the cost over the monthly charges).

I don't see a real difference between A and B, they're effectively identical save that you CAN use a wild card cert for A, you just don't HAVE to. Without the wild card aspect, A == B, the fact that they're all subdomains of example.com is coincidence.

Even with option A at the beginning, you have room later to expand to option B if that's the kind of service feature you'd like to offer your clients.