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 partit

Answer 1

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 2

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 3

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 4

Option B has a a lot of value for users and if I had the choice I'd go this route. Keep in mind that you can buy multi-domain ssl certificates / UCC and you can get up to 100 domains under one certificate. If there are other certs out there that allow more then 100 - let me know because we're building an SAAS model as well and having similar questions.

Answer 5

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