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

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.

Answer 2

You're right Will, A and B are the same. However, I think that is true mainly from a coding perspective. With either option, the web server will determine the account based on the host name in the HTTP header. C is slightly different from a coding perspective because it would match the account based on the path under the domain name, and the ASP.NET MVC framework's URL routing capabilities would come in handy here.

From an administrative perspective each option is quite different. With option A we would have to manage the subdomains... which we can do because our DNS provider has an API to manage host records. With option B we would have to manage the private keys for all the different domain names, as I mentioned.

I'm guessing from the number of responses that this is not the best type of question to ask on this forum, probably because it is too open ended. I was just hoping that someone who has been there and done that would chime in, mainly so I know if I'm even on the right track, as I've never designed a system like this before.

Thanks

Answer 3

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 4

Hi All,

I would use secure.domain.com instead of certificate for www.domain or domain.com I've seen many sites that use certificates for one of the options (either with or without the www prefix) and when the user uses the other (s)he gets prompted for certificate acceptance.

You could use user.domain.com for a non-secure site and when the user needs an SSL enabled section just use your main secure.domain.com/user/ .......

That's just an idea.

Slavi