Petro123arkhimedдублировать не нужно, если зашли на свою страницу
ты веб-программист?
Если куки пустые, то что значит своя страница?
Если клиент-сервер, то пиши в своём логине-окне что захочется.
Даже виндовую авторизацию на сиквел.

под своей страницей я имею ввиду страницу своей организации по адресу org1.mydomain.ru

т.е. существует сразу несколько адресов:
- org1.mydomain.ru
- org2.mydomain.ru
- orgN.mydomain.ru

они смотрят на один и тот же app-сервер
веб приложение может сразу определить по url, что это за организация, а если такой нет показать page not found

Нахлобучarkhimedв части проектирования базы данных уже решено отказаться от упоминания в каждой таблице ссылки на учетную запись. Вместо этого под каждую организацию будет выделяться отдельная схема, в которой будут представлены все необходимые таблицы.
Как будете выходить из ситуации, когда в версии N+1 всего программного комплекса в схему БД будут внесены обратно-несовместимые изменения?

Ситуация: веб-приложение уже обновлено до версии N+1, какие-то схемы уже на версии N+1, а десяток схем всё еще на версии N.

хороший вопрос
тут мысли такие:
выбранная архитектура как раз позволит производить частичное обновление версий
а также можно будет добавлять какие-то кастомные объекты бд в схеме организации

согласен, что сейчас сервер приложений один, надо думать
возможно придется накатывать обновления на все базы, на которые смотрит один сервер приложений

Нахлобучarkhimedвыбранная архитектура как раз позволит производить частичное обновление версий
а также можно будет добавлять какие-то кастомные объекты бд в схеме организации
Вернее, выбранная архитектура позволит набить себе много шишек в интересных местах из-за неизбежного расхождения в версиях веб-приложения, схемы БД и наборах объектов в оных.

В случае, когда есть, грубо говоря, одна БД (всякие кластеры и Failover'ы для упрощения не рассматриваем) и N веб-серверов, обновление тривиально.

Когда на БД накатываются только обратно-совместимые миграции, веб-сайт можно даже не останавливать: бэкапим, применяем миграции, и, в случае успешного выполнения, простой Rolling Update на веб-сервера.

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

В случае же нескольких БД всё становится интереснее. Если один веб-сервер смотрит на несколько БД и на одной из них миграции не применились, то получаем ворох ошибок. Если из пула веб-серверов взялся сервер со старой версией кода и он пытается обработать запрос к обновленной БД -- тот же ворох ошибок.

обновление будет делаться скриптами по всем базам
на время обновления также вешаем заглушку
причем можно сделать обновление на одной группе db и app серверов

Petro123arkhimed,
Нельзя без ведома хозяев обновлять скриптами.

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

Олег2015Необходимо вынести аутентификацию в отдельную подсистему, это позволит сосредоточиться на уровне приложений только на авторизации и бизнес-логике, а система аутентификация будет озадачена ведением оргструктуры (пользователи, организации), назначением привилегий, ролей, предоставление нескольких протоков аутентификации (WS-Federation, SAMl2p, OpenID и т.д.). Пользователи веб-приложение аутентифицируются при помощи WS-Federatiom, толстые клиенты могут использовать WS-Trust, а мобильные - OpenID, причем вместо ввода логина и пароля может применяться eToken. А еще SSO, home realm discovery, ГОСТовские алгоритмы шифрования (что очень важно для гоструктур).

сейчас как раз изучаю этот вопрос
честно говоря, в последнее время столько всего появилось в этой области, что легко запутаться

насколько я понимаю, нужно использовать windows identity foundation: в нем заложены все нужные режимы. или я не прав? хочется сделать унифицированную схему аутентификации и авторизации для веб-сайта и api для толстого клиента.

skyANAarkhimedпотенциальных организаций-пользователей системы не так много (<100), а функций много.Хм... у нас 15000 организаций-пользователей в одной базе и функций тоже не мало :)

Хотя биллинг и платежи вынесены в отдельную БД на том же сервере.

Вы ещё скажите у вас у каждой ассоциации планируется своя domain model, иначе зачем им отдельные схемы?

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

насчет domain model, поясните, пожалуйста, что имеете ввиду?

skyANAА насчёт dns-записи, то у каждого клиента она своя.

у вас это используется для каких целей?
я думаю это использовать именно с целью направления клиентов на "свои" app-сервера.
т.е. на условно 50 организаций на одной группе app-сервер+db-сервер, еще 50 на другой и т.п.
причем эти группы будут располагаться в разных географических зонах.

еще вопрос по этому поводу:
мы, конечно, будем использовать ssl режим.
на один веб-сервер будет смотреть несколько записей:
org1.mydomain.ru CNAME server1.mydomain.ru
org2.mydomain.ru CNAME server1.mydomain.ru
orgN.mydomain.ru CNAME server1.mydomain.ru

не будет ли проблем с ssl-сертификатом и настройкой IIS? или wildcard-сертификат решит все вопросы? просто никогда еще не использовал такую схему.

Petro123skyANA,
я думаю, ему нужно как можно проще.
Из-за этого он шифрует в логин имя поддомена. Что я не очень приветствую.
ТЗ (которое он не колется):
- каждой организации свой экземпляр 1С.
- авторизация самой 1С должна дружить с авторизацией и билингом надсистемы Облако.
- смена версий ПО в облаке решается желанием заказчика (может заморозить).

Уважаемый Petro123,

еще раз повторю:
нет никакого 1С, разработка полностью своя с нуля.
думаем использовать подход хранения в разных схемах по нескольким причинам:
1. упрощенная разработка схем таблиц и процедур (нет необходимости везде вводить поле AccountId).
2. для некоторых крупных клиентов можно предоставить прямой доступ к их схеме.
3. всегда можно достаточно легко вынести данные клиента в отдельную бд и отдать ему.
4. у каждого клиента будет достаточно много данных, несколько миллионов строк. таких клиентов будет, например, около 100.
намного проще разнести их данные на несколько бд и серверов, причем в зависимости от требований клиентов можно будет предоставлять разный регламент бекапирования и т.п.

Господа,
не нужно думать, что есть только системы, в которых много пользователей и мало данных у каждого.
есть и другие примеры, когда пользователей мало, но данных у каждого много.
и тогда нужно применять немного другие подходы.

при этом буду рад любым замечаниям и идеям. сейчас проект в стадии осмысления и всё еще можно поменять.