Многопользовательская модель пользователя

Question

В многопользовательской системе, в которой размещаются несколько организаций и приложений, где организация может использовать несколько приложений, размещенных в системе, должна ли моя модель пользователя и роли быть такой, чтобы один пользователь или роль могли существовать в нескольких приложениях и организациях?Или я должен ограничить пользовательский объект одной парой организация / приложение, а затем определить некоторую всеобъемлющую модель, чтобы связать эти пользовательские объекты вместе?

То есть:

• Джон Доуэто человек

• Он хочет использовать ApplicationA и ApplicationB

• Он работает в двух разных компаниях (просто терпите меня), OrganizationA и OrganizationB

Если модель пользователя:

1. johndoe @ someuniquesuffix - его уникальное имя пользователя.Это дает ему доступ к обоим приложениям для обеих организаций.

2. johndoe @ applicationa @ organizationa - это его имя пользователя для ApplicationA в OrganizationA.johndoe @ applicationb @ organizationa - это его имя пользователя для ApplicationB в OrganizationA ... и то же самое для OrganizationB.Затем есть некоторый «главный» список, в котором говорится, что все 4 учетные записи пользователей для приложений / организаций соответствуют одному и тому же фактическому «человеку», Джону Доу?

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

Спасибо за любую помощь!

Answer 1

ИМО, вы должны ограничить каждый набор учетных данных для организации.Кроме того, вы должны включить возможность для каждого приложения ограничивать то, что пользователи в этой организации могут делать с каждым приложением.То есть каждое приложение должно управлять своими ролями авторизации.Вам нужны некоторые средства, чтобы справиться со сценарием, когда Джо покидает Организацию А, но продолжает работать в Организации Б.

Answer 2

Лично я считаю, что отслеживание того, что Джон Доу является одним человеком, работающим как в Организации А, так и в Организации В, значительно усложняет ситуацию, не прибавляя большого значения в большинстве случаев . Если у вас нет четкой бизнес-причины понять в вашей модели, что Джон Доу из A такой же , что и Джон Доу из B, я бы от этого отказался. Поддержание вашей пользовательской базы данных во всех организациях, необходимость иметь дело с уникальными именами для всех организаций («Что вы имеете в виду, что уже есть Джон Доу? Это не я!») И наличие модели UI (например, спрашивая пользователя при входе в систему «хотите ли вы работать с данными А сегодня или с данными Б?», это добавляет существенные сложности.

Единственным недостатком моей рекомендации является то, что если вы используете сторонний аутентификатор, такой как OpenID или OAuth, то человек, имеющий несколько арендаторов, должен войти в систему с разными идентификаторами. Например. Я вхожу в систему с помощью Google OpenId. В результате я получаю данные A, но для работы с B мне нужно использовать учетную запись Twitter, потому что мой идентификатор Google уже привязан к A и только A.