Дизайн URL для приложения SaaS, защищенного SSL

Question

Я занимаюсь разработкой приложения с использованием платформы ASP.NET MVC, которая будет представлена ​​в виде службы через Интернет (модель SaaS ). Я пытаюсь определить лучший способ разделения пространства имен URL для каждой учетной записи пользователя. К приложению необходимо будет получить безопасный доступ через SSL, поэтому моя главная проблема заключалась в том, чтобы придумать дизайн URL, который хорошо работает с SSL-сертификатами. Вот варианты, которые я придумал. В каждом примере bob и jane являются двумя примерами учетных записей пользователей:

Вариант A: каждая учетная запись имеет уникальный поддомен под общим доменным именем

, например

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

• Для этого потребуется подстановочный SSL сертификат (например, сопоставлен с * .example.com), чтобы каждый пользователь мог беспрепятственно получить доступ к своей учетной записи через SSL. Под бесшовным я имею в виду без веб-браузер, предупреждающий пользователя о Проблемы с сертификатом SSL. Единственный недостаток, который я могу придумать, заключается в том, что сертификаты подстановочные значительно дороже, чем нормальные фиксированные доменные сертификаты. Цена Разница, безусловно, будет незначительный в грандиозной схеме вещи, но это то, что я имея в виду, если все остальное докажет быть равным.

Вариант B: каждая учетная запись имеет уникальное доменное имя

, например

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

• В этом случае каждому пользователю будет привязан сертификат SSL на их доменные имена. Один большой недостаток, который я могу придумать, заключается в том, что наш серверы должны были бы поддерживать закрытые ключи для всех пользователей сертификаты, и мы должны были бы разработать система, которая позволила пользователям безопасно передавать свои закрытые ключи к нашим серверам. Даже если бы у нас было такое система, я чувствую, что это будет слишком большая часть нагрузки на пользователей должна получить сертификат и отправить личные ключи к нам.

• В качестве альтернативы, мы могли бы автоматически выдавать и предоставлять SSL-сертификат для каждого пользователя при они регистрируются, чтобы они могли начать доступ к своему приложению через SSL без дополнительные шаги Это будет требуют, чтобы мы стали эмитентом SSL-сертификаты, которых у меня нет посмотрел еще ... скорее всего, мы бы быть посредником для какого-то другого большого такая компания, как Verisign, которая специализируется на таких вещах.

• Несмотря на кажущуюся боль этого подход, эта опция позволяет некоторые функции, которые мы можем захотеть обеспечить в будущем, т.е. пользователь иметь свой собственный бренд версия приложения доступна через доменное имя собственной компании.

Вариант C: каждая учетная запись имеет уникальный подкаталог под общим доменным именем

* * Например, одна тысяча тридцать восемь

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

• С точки зрения SSL сертификат обслуживания, это наверное лучший вариант. Мы будем нужен только один сертификат SSL для фиксированного домена (например, example.com), который будет используется всеми пользователями.

• К сожалению, этот дизайн URL не работает хорошо с другими аспектами нашего нынешнего архитектура приложения, особенно вокруг балансировки нагрузки.

Нужна обратная связь

Мой вопрос ко всем вам: какой вариант вы бы выбрали и почему? Мне бы особенно хотелось услышать примеры и опыт из реальной жизни, но любые другие вопросы или проблемы, которые я еще не представил, были бы оценены.

Answer 1

Я бы выбрал A. Это решение не очень дорогое, оно хорошо масштабируется и не ограничивает вас в использовании пользовательских доменов, если вы решите это позже.

Сертификаты с подстановочными знаками раньше были довольно дорогими, но сегодня вы можете получать их по 200 долларов в год по GoDaddy или RapidSSL , что, на мой взгляд, довольно дешево. Эти сертификаты работают (почти) в любом браузере, но они не поставляются с проверкой, обеспечивает VeriSign. Я не знаю, нужно ли вам это.

Если вы воспользуетесь опцией B, вам придется купить сертификат для каждого пользователя, но с использованием группового сертификата, сертификат будет оплачен после нескольких регистраций, а остальная сумма будет чистой прибылью.

Помимо этого, решение очень просто реализовать, что также является преимуществом.

Answer 2

Вариант B имеет большую ценность для пользователей, и если бы у меня был выбор, я бы пошел по этому пути. Имейте в виду, что вы можете купить многодоменные ssl-сертификаты / UCC и получить до 100 доменов под одним сертификатом. Если есть другие сертификаты, которые допускают более 100 - дайте мне знать, потому что мы также строим модель SAAS и имеем похожие вопросы.

Answer 3

Звучит как вариант B для меня. Это единственное, что, кажется, а) работает с вашей архитектурой и б) работает с вашими потенциальными будущими целями. Вы можете сделать цену сертификата SSL для пользовательских доменов частью первоначальной стоимости услуги (или амортизировать стоимость сверх ежемесячной платы).

Я не вижу реальной разницы между A и B, они фактически идентичны, за исключением того, что вы МОЖЕТЕ использовать сертификат подстановочного знака для A, просто не ДОЛЖНЫ. Без подстановочного знака, A == B, тот факт, что все они являются поддоменами example.com, является совпадением.

Даже с опцией A в начале, у вас есть место для расширения до варианта B, если вы хотите предложить своим клиентам такую ​​услугу.

Answer 4

Я бы использовал secure.domain.com вместо сертификата для www.domain или domain.com Я видел много сайтов, которые используют сертификаты для одного из вариантов (с префиксом www или без него), и когда пользователь использует другие, ему предлагается принять сертификат.

Вы можете использовать user.domain.com для незащищенного сайта, а когда пользователю нужен раздел с включенным SSL, просто используйте свой основной secure.domain.com/user/ .......

Это просто идея.

Славяне

Answer 5

Вы правы, Воля, А и Б одинаковы. Тем не менее, я думаю, что это верно в основном с точки зрения кодирования. В любом случае веб-сервер будет определять учетную запись на основе имени хоста в заголовке HTTP. C немного отличается от перспективы кодирования, потому что он будет соответствовать учетной записи на основе пути под доменным именем, и возможности маршрутизации URL-адресов инфраструктуры ASP.NET MVC здесь пригодятся.

С административной точки зрения каждый вариант совершенно другой. При использовании опции А нам придется управлять поддоменами ... что мы можем сделать, потому что у нашего провайдера DNS есть API для управления записями хоста. При использовании опции B нам придется управлять закрытыми ключами для всех разных доменных имен, как я уже говорил.

Я полагаю по количеству ответов, что это не лучший тип вопросов на этом форуме, вероятно, потому что он слишком открытый. Я просто надеялся, что кто-то, кто был там и сделал это, присоединится, в основном, так что я знаю, нахожусь ли я даже на правильном пути, поскольку я никогда раньше не проектировал такую ​​систему.

Спасибо