Да, вы можете
1) Вы ДОЛЖНЫ быть готовы настроить доверие на нескольких виртуальных / физических серверах. Это главное преимущество JWT в том, что он может быть объединен. Это не зависит от баз данных за пределами веб-приложений. Если вы собираетесь использовать более одного веб-сервера для этого приложения, они должны доверять друг другу.
Полагаю, вы можете попробовать один из:
i) Ваш сервер аутентификации должен быть закодирован / настроен для доверия доменам / машинам в вашем решении
см. https://blogs.msdn.microsoft.com/webdev/2017/04/06/jwt-validation-and-authorization-in-asp-net-core/
Особо обратите внимание на строки «Аудитория» и «Авторитет» и исследуйте эти концепции.
ii) Рассматривать внешний JWT как надлежащие «внешние» учетные данные (например, Google OAuth), а затем инициализировать локальный JWT или другой механизм безопасности после обращения к внешнему токену. Я должен найти ссылки для этого.
2) Вы ДОЛЖНЫ иметь отдельный поддомен для каждого клиента (см. Далее ниже после горизонтального правила)
3) Вы ДОЛЖНЫ исправить свою стратегию инициализации контекста БД. Метод GetOwinContext - ужасная реализация шаблона IoC. Код JWT UserManager по умолчанию ожидает, что контекст БД будет получен из одноэлементной ссылки OwinContext. Если вы обращаетесь к нескольким базам данных, это проблема. Один из способов - просто создать контекст по требованию на данный момент, а затем подумать о способах оптимизации повторного использования и производительности. Это, вероятно, важно, потому что вам нужно убедиться, что он проверяет правильную базу данных для любого запроса.
Вот одна ссылка на решение: Как изменить имя базы данных в строке подключения dbcontext во время выполнения
4) У вас есть клиенты, которым необходим доступ к нескольким базам данных. Есть несколько способов сделать это. В идеале вы должны поддерживать федеративный шаблон в максимально возможной степени. Но вам также может понадобиться / нужна оркестровка на стороне сервера: специальные API помимо CRUD, которые специализируются для задач с несколькими базами данных. У вас будет действие на стороне сервера для каждого фиксированного отчета. Такое действие на стороне сервера будет рассматривать запрос к базам данных для запроса (с точки зрения CustomerID), оно будет проверять доступ через настраиваемое требование JWT (набор CustomerID), оно будет выдавать исключение, если какие-либо указанные кастомериды не разрешено Тогда функция будет выполняться по желанию с этими проверенными пользователями в ссылке. Смотрите [5] о том, как это может работать.
Вот несколько ссылок для создания пользовательских утверждений JWT (они хранятся в JWT, передаются клиенту и от него через заголовок Bearer [обычно]):
Вот несколько ссылок для получения пользовательских утверждений JWT:
5) Распространено объединение набора данных. Это может иметь место для вас. Если базы данных находятся в одном и том же экземпляре СУБД, обычно выполним запрос к нескольким базам данных в одном операторе SQL (для SQL Server). (Тем не менее, если вы используете пул баз данных Azure, они, как правило, работают на разных экземплярах (прозрачно). Я полагаю, что недавно произошли изменения, которые либо позволяют вам указать, что они находятся в одном экземпляре, либо теперь позволяют запросы к нескольким базам данных). В противном случае оркестровка на стороне сервера означает, что вы получите топ-10 из каждой базы данных в отдельности, затем выполните окончательную сортировку и топ-10 для отправки клиенту. В худшем случае вам потребуется, чтобы клиент делал запросы несколько раз, один раз для каждой клиентской базы / базы данных, а затем на стороне клиента собирая данные.
(я уже рассмотрел несколько моментов, пожалуйста, дайте мне знать, о чем вы хотели бы узнать подробнее)
Мне нравится база данных на клиента
Похоже, вы описываете систему, в которой для каждого клиента существует отдельная база данных. Когда вы будете иметь дело с клиентами, которые не нуждаются в обмене данными внутри приложения: это дизайн, за который я большой сторонник. Он изолирует доступ к данным (безопасность / конфиденциальность), снижает конкуренцию за блокировку таблиц (производительность) и позволяет перемещать базы данных на разные серверы для обеспечения близости и балансировки нагрузки (производительность).
all company logins with same login screen.
Это требование - ваше самое большое препятствие. Если вы когда-либо использовали Slack, вы заметите, что они создали новый поддомен для каждой команды. Каждой команде не нужно делиться учетными данными.
Этот дизайн с наличием отдельных поддоменов означает:
- Веб-сервер также является переносимым компонентом; в дополнение к базе данных.
- Клиент может настроить свою собственную запись DNS в качестве тщеславного URL (например, yourapp.acmeco.com); а также ваш собственный поддомен по умолчанию (например, acmeco.yourapp.com)
Независимо от ответа на вашу конкретную проблему, я настоятельно рекомендую вам поговорить с заинтересованными сторонами вашего проекта, чтобы узнать, можно ли реализовать проект с несколькими поддоменами.
Для простоты настройки (обратитесь к веб-приложению) я настоятельно рекомендую:
- Настройка записи DNS с подстановочными знаками (я знаю, что это поддерживается по крайней мере с CloudFlare)
- Вы ДОЛЖНЫ получить сертификат SSL с подстановочным знаком, чтобы легко шифровать каждый поддомен. Это должно стоить около 100 долларов за 1-2 года. Не платите за дополнительные функции, это пустая трата денег IMO.
- Настройте свой веб-сервер без определенного хоста. (Если у вас есть другие веб-приложения, настроенные вместе с тем же IP-адресом, у них может быть еще имя хоста и общий порт 80/443). В IIS это просто означает, что область URL-адреса хоста остается пустой.
- Вам понадобится ваше приложение для обработки JWT / Session, чтобы проверить, к какой базе данных подключаться. При входе в систему необходимо проверить заголовок хоста, чтобы определить, к какой базе данных подключаться.