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

Question

Я работаю над мультитенантным облачным приложением и рассматриваю возможность использования адресов электронной почты / паролей для общих учетных данных для входа.Однако у меня может быть один и тот же пользователь (один и тот же адрес электронной почты), связанный с несколькими арендаторами на основе модели запланированных продаж для этого приложения.Например, несколько отделов в одной компании могут быть отдельными арендаторами, или отдельные компании должны быть отдельными арендаторами.В любом случае один и тот же пользователь (с тем же адресом электронной почты) может быть пользователем этих разных арендаторов.

Каковы возможные стратегии проектирования для решения такой ситуации?

Один подход, который я рассматриваюотделяет создание и обновление учетных данных электронной почты пользователя от арендаторов.При таком подходе арендатор может пригласить пользователя (отправив электронное письмо), и пользователь может использовать одинаковые учетные данные для доступа ко всем арендаторам, просто переключаясь между арендаторами по желанию.

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

Спасибо.

Answer 1

Предполагая, что ваш вопрос касается технического проекта (а не пользовательского опыта), это довольно простое решение. Создайте пользователей независимо от арендаторов и учтите отношение «многие ко многим», представляющее фразу «имеет доступ к».

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

1. СУБД: создание пользовательской таблицы, таблицы клиентов и таблицы отношений user_has_access_to
2. Сервер каталогов (LDAP): поместите пользователей в одно подразделение в каталоге и создайте арендаторов в качестве групповых объектов. Затем пользователи могут иметь атрибут memberOf для каждого арендатора, к которому они имеют доступ.

Указанная выше опция LDAP имеет ограничение на перегрузку объекта группы. Если вы достаточно знакомы с определениями схемы LDAP, вы можете с легкостью создать объект-арендатор и добавить атрибут hasAccessToTenant в свой пользовательский объект. Использование этого подхода позволит вам использовать группы для представления фактических групп пользователей (так как тип объекта должен был использоваться).

Более продвинутый вариант дизайна будет включать создание отношений «имеет доступ» между арендаторами. Добавление этого вместе с отношением пользователя к арендатору откроет более сложное моделирование отношений. Например: арендатор с отделами или отделами, позволяющий пользователям с разрешениями для арендатора верхнего уровня автоматически «иметь доступ» к подразделениям.

Answer 2

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

Настоящей проблемой является опыт, который приложение может предложить таким пользователям. Им потребуется специальная целевая страница, которая позволит им выбирать между пространствами имен. Выбранное пространство имен должно быть квазипостоянным во время сеанса, то есть до тех пор, пока пользователь не выйдет из системы. (Я пытаюсь реализовать это в новом приложении на GAE / Python27)

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