Многопользовательское приложение ASP.NET с ролями, зависящими от клиента

Я не думаю, что вы сможете внедрить мультиарендность в какой-либо нестандартный поставщик ролей, поэтому вы можете продолжать использовать SqlMembershipProvider (и SqlRoleProvider). Даже новейшая версия Microsoft.AspNet.Identity по-прежнему предполагает ванильный принцип «многие ко многим» между пользователями и ролями. Что вам действительно нужно, так это добавить третий столбец к первичному ключу этой таблицы многие-ко-многим, который будет идентифицировать вашего клиента, то есть:

user: 6
role: 4
tenant: 17

user: 6
role: 9
tenant: 18 (and so on)

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

Если вы выбрали вариант №2, ваши атрибуты [Authorize] взорвутся. Представьте себе это:

[Authorize(Roles = "TenantA:Admin", "TenantB:Admin", ...)]
public ActionResult Post(int id, SomeViewModel model) {}

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

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

Преимущества

1. Данные арендатора по умолчанию разделены на разные базы данных.
2. Данные арендатора могут быть экспортированы как дамп базы данных для клиентского MI.
3. Дизайн базы данных значительно упрощен

Недостатки

1. Вам нужно управлять несколькими базами данных - операционная задача
2. Вам необходимо разработать код переключения базы данных

Реализация с использованием нескольких баз данных

1. Мы использовали базу данных конфигурации, в которой есть настройки клиента на основе кода учетной записи. Этот код учетной записи может быть получен с экрана входа в систему, или вы можете сопоставить субдомен с кодом клиента.
2. Когда приложение запускается, вы загружаете всех клиентов в кеш (содержащий строки подключения)
3. По каждому запросу вы должны определить клиента, а затем переключить контекст db

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

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

Что не работает

Идеальной альтернативой было бы динамически переключать ApplicationName, но хотя кажется, что это работает, ApplicationName не является потокобезопасным, поэтому это будет ненадежно:

Поскольку для всех запросов, обслуживаемых объектом HttpApplication, используется один экземпляр поставщика членства по умолчанию, вы можете иметь несколько запросов, выполняемых одновременно и пытающихся установить значение свойства ApplicationName. Свойство ApplicationName не является потокобезопасным для нескольких операций записи, а изменение значения свойства ApplicationName может привести к неожиданному поведению нескольких пользователей приложения. Мы рекомендуем вам избегать написания кода, который позволяет пользователям устанавливать свойство ApplicationName, за исключением случаев, когда это необходимо. Примером приложения, в котором может потребоваться установка свойства ApplicationName, является административное приложение, которое управляет данными членства для нескольких приложений. Такое приложение должно быть однопользовательским, а не веб-приложением.

Альтернатива: MembershipReboot

Многопользовательская среда - это сложная задача в .Net. Альтернативой встроенному членству с открытым исходным кодом является использование MembershipReboot, написанного Брок Аллен. Он имеет несколько отличных функций, включая поддержку мультитенантности прямо из коробки:

1. управление одно- или многопользовательской учетной записью
2. гибкий дизайн хранилища учетных записей (реляционный / SQL или объектный / NoSql), примеры с использованием EF и RavenDB
3. идентификационные данные пользователей с учетом утверждений
4. поддержка регистрации учетной записи, проверки электронной почты, сброса пароля и т. д.
5. блокировка учетной записи за несколько неудачных попыток входа в систему (угадывание пароля)
6. расширяемый шаблон для уведомлений по электронной почте
7. настраиваемое имя пользователя, пароль и проверка адреса электронной почты
8. система уведомлений об активности и обновлениях учетной записи (например, для аудита)
9. связь учетной записи с внешними поставщиками удостоверений (корпоративными или социальными)
10. поддерживает аутентификацию на основе сертификатов
11. правильное хранение паролей (через PBKDF2)
12. настраиваемые итерации
13. по умолчанию - рекомендации OWASP для итераций (например, 64 КБ в 2012 году)
14. поддержка двухфакторной аутентификации с помощью SMS-сообщений мобильного телефона или клиентских сертификатов

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

Альтернатива: ServiceStack REST

Другой альтернативой, если вы создаете современные веб-приложения, активно использующие фреймворки JavaScript MVC, такие как AngularJS, EmberJS или BackboneJS, является использование сервисов ServiceStack REST. ServiceStack имеет длинный список функций аутентификации, и из моего опыта SS, я считаю, что у него очень хорошо продуманная модель API.