Как сделать авторизацию в приложении с несколькими базами данных?

Question

[JayBerkutie]

Возникла задача переделать систему авторизации в приложении.
Сейчас база каждой организации развернута на отдельных поддоменах и выглядит все это так


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


Вопрос возникает в том, как делать запрос на проверку существования пользователя во всех базах при авторизации? Количество баз планируется увеличивать. А пользователь может одновременно находиться в нескольких базах одновременно.

Comments

[Илья Чубаров]

Хм интересный вопрос, как при такой архитектуре создавать сессию, а можете добавить именно описание в бизнес потребностях?

[JayBerkutie]

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

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

Была мысль сделать отдельную БД, где будут хранится все уникальные пользователи, уникальность проверяется по СНИЛС, и в ней же хранить привязку пользователь - БД, и при каждом переключении между БД, пользователю выдается токен и он бы проверялся, при каждом запросе к серверу, но боюсь. это скажет на производительности.

[Илья Чубаров]

JayBerkutie, я думаю что вы мыслите в правильном направлении.
Тут надо разделить процесс аутентификации, есть ли в сис-ме пользователь и процесс авторизации(может ли войти как сотрудник например)
Создаем центральный сервис (далее как ЦС) и все клиенты будут проходят через одну точку доступа.
Соответственно каждый клиент(организация) создает локальную сессию. Это решит вопрос входа через один UI.
Далее зависит уже от инфраструктуры.
Есть такое понятие SSO но не совсем вписывается для разных ролей. На сколько мне известно, так работает google сервисы.
Далее есть OpenID и протокол Auth 2.0 все это для решения проблем с аутентификацией и авторизацией в разных сетевых сис-ах.

Если у вас сами сервисы разграничивают права, то есть если вы точно уверены что инвариант будет соблюден:
Пользователь N в сервисе N (organization на вашей схеме) всегда будет имеет 1 определенную роль.
То вся задача сводиться к аутентификации, то есть вынести всех в отдельный сервис.
Конечно проверять пользователя в локальной базе быстрее чем сетевой запрос, но это оптимальное решения для разделения.
Можно дополнительно например кэшировать, или определить контрольные точки для проверки в ЦС.

[JayBerkutie]

Илья Чубаров, благодарю Вас за ответ ;)

Answer 1

[JhaoDa]

Создать кастомную реализацию контракта UserProvider, в которой «делать запрос на проверку существования пользователя во всех базах».

Answer 2

[Константин Б.]

Я бы вам посоветовал объединить и вынести юзеров в еще одну базу коль у вас их и так как говна. Это будет куда элегантнее чем сейчас, тем более что планируете их рост.

Кстати, судя по всему у вас сейчас неправильная архитектура, которая требует переработки, в вашем случае идет нарушение нормальных форм

По идеи у вас должно быть примерно так

users - Таблица всех пользователей
organizations - все фирмы
user_organization - связь привязка юзера к организации, но дополнительно здесь вы указываете какая роль у вашего пользователя именно в данной организации, то есть поля такие user_id, organization_id, role_id

Ну и т.д., например возьмем еще какой-нибудь тип данных, пусть это будут услуги оказываемые организацией, тогда они будут иметь таблицу services c полем organization_id и остальными полями

В общем все достаточно просто распределяется

Comments

[JayBerkutie]

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

[Константин Б.]

JayBerkutie, не могу ответить на этот вопрос не зная всего приложения. Предположительно дополнил в ответе

[JayBerkutie]

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