Универсальное руководство по настройке аутентификации и авторизации для многопользовательской среды
Создание многопользовательского приложения может быть сложной задачей. Эта статья объединяет все наши предыдущие публикации о стратегиях многопользовательской и организационной структуры. Мы надеемся, что это поможет сэкономить ваше время и легко начать работу.
Product & Design
Построение многопользовательского приложения может быть сложной задачей, требующей учета множества аспектов. Данная статья компилирует все наши предыдущие блоги о понимании многопользовательских и организационных практик. Для быстрого старта и экономии времени просто ознакомьтесь с этой статьей, она включает все необходимое!
Основные рекомендации описаны в следующих шагах:
- Понять многопользовательскую архитектуру
- Картировать ваши сценарии использования многопользовательского приложения
- Добиться изоляции арендаторов
- Определить, как вы хотите управлять идентичностями
- Выбрать соответствующую модель авторизации
Что такое многопользовательская архитектура
Многопользовательская программная архитектура — это программная архитектура, при которой один экземпляр программы работает на сервере и обслуживает несколько арендаторов. Системы, спроектированные таким образом, являются "общими" (в отличие от "выделенных" или "изолированных").
Арендатор — это группа пользователей, которые имеют общий доступ с определёнными привилегиями к экземпляру программы.
Одной из ключевых концепций многопользовательской среды является "общий". В более широком определении многопользовательской среды быть многопользовательским приложением не означает, что каждый компонент в решении является общим. Скорее, это означает, что по крайней мере некоторые компоненты решения используются повторно несколькими арендаторами. Понимание этого термина в широком смысле поможет лучше понять потребности клиентов и откуда они исходят.
Как только вы поймете многопользовательскую архитектуру, следующим шагом будет применение вашего приложения в реальных сценариях, с акцентом на конкретные продуктовые и бизнес-потребности.
Какие есть сценарии использования многопользовательских приложений?
Многопользовательская модель в SaaS
Многопользовательские приложения часто находят своё место в B2B-решениях, таких как инструменты для повышения продуктивности, программное обеспечение для совместной работы и другие продукты программного обеспечения как услуги (SaaS). В этом контексте каждый "арендатор" обычно представляет делового клиента, у которого может быть несколько пользователей (его сотрудников). Кроме того, деловой клиент может иметь несколько арендаторов для представления различных организаций или бизнес-подразделений.
Многопользовательская модель в общих B2B-сценариях
B2B-приложения выходят за рамки продуктов SaaS и часто подразумевают использование многопользовательских приложений. В контексте B2B эти приложения служат общей платформой для различных команд, деловых клиентов и компаний-партнеров с целью доступа к вашим приложениям.
Например, возьмем компанию, оказывающую услуги по совместному использованию автомобилей, которая предлагает как B2C, так и B2B-приложения. B2B-приложения обслуживают нескольких деловых клиентов, и использование многопользовательской архитектуры может помочь в управлении их сотрудниками и ресурсами. Для иллюстрации, если компания хочет сохранить единую систему идентификации пользователей, она может спроектировать архитектуру, как в следующем примере:
Сара имеет как личную, так и деловую идентичности. Она использует сервис совместного использования автомобилей как пассажир, а также работает водителем в свое свободное время. В своей профессиональной роли она также управляет своим бизнесом и использует эту деловую идентичность, чтобы быть партнером с Бизнесом 1.
Почему следует использовать многопользовательскую модель в продукте SaaS
Масштабируемость с многопользовательской моделью
Для корпоративных бизнесов многопользовательская модель является ключом к эффективному удовлетворению их требований по доступности, управлению ресурсами, управлению затратами и безопасности данных. На техническом уровне принятие многопользовательского подхода упрощает ваши процессы разработки, минимизирует технические сложности и способствует бесшовному расширению.
Создание единого опыта
При изучении корней продуктов SaaS, это похоже на здание, в котором находятся различные квартиры. Все арендаторы пользуются общими коммунальными услугами, такими как вода, электроэнергия и газ, но при этом сохраняют независимый контроль над управлением своим пространством и ресурсами. Этот подход упрощает управление недвижимостью.
Обеспечение безопасности через изоляцию арендаторов
В многопользовательской архитектуре термин "арендатор" вводится для создания границ, которые отделяют и защищают ресурсы и данные различных арендаторов в рамках единого экземпляра. Это гарантирует, что данные и операции каждого арендатора остаются отдельными и безопасными, даже если они используют одни и те же основные ресурсы.
Почему необходимо добиться изоляции арендаторов?
Когда говорят о многопользовательских приложениях, всегда нужно добиваться изоляции арендаторов. Это означает сохранение даных и ресурсов различных арендаторов раздельными и защищёнными в общей системе (например, облачной инфраструктуре или многопользовательском приложении). Это предотвращает любые несанкционированные попытки доступа к ресурсам другого арендатора.
Хотя объяснение может показаться абстрактным, мы приведём примеры и ключевые подробности, чтобы дополнительно объяснить психологию изоляции и лучшую практику достижения изоляции арендаторов.
Изоляция арендаторов не противоречит "общему" подходу многопользовательской среды
Это потому, что изоляция арендаторов необязательно является конструкцией уровня инфраструктурных ресурсов. В области многопользовательской среды и изоляции некоторые смотрят на изоляцию как на строгое деление между фактическими инфраструктурными ресурсами. Это обычно приводит к мод ели, в которой у каждого арендатора есть отдельные базы данных, вычислительные экземпляры, учетные записи или частные облака. В сценариях общих ресурсов, таких как многопользовательские приложения, способ достижения изоляции может быть логической конструкцией.
Изоляция арендаторов фокусируется исключительно на использовании контекста "арендатора" для ограничения доступа к ресурсам. Она оценивает контекст текущего арендатора и использует этот контекст для определения, какие ресурсы доступны для этого арендатора.
Аутентификация и авторизация не равны "изоляции"
Использование аутентификации и авторизации для контроля доступа к своим средам SaaS важно, но недостаточно для полной изоляции. Эти механизмы являются всего лишь частью головоломки безопасности.
Люди часто задают вопрос: могу ли я использовать общие решения авторизации и контроль доступа на основе ролей для достижения изоляции арендаторов?
Вот в чём дело: вы можете построить мн огопользовательское приложение, но не можете сказать, что вы достигли и использовали стратегии изоляции арендаторов как лучшую практику. Мы обычно не рекомендуем это потому что
Для иллюстрации, рассмотрим ситуацию, в которой вы настроили аутентификацию и авторизацию для своей системы SaaS. Когда пользователи входят в систему, они получают токен, содержащий информацию о их роли, определяющую, что они могут делать в приложении. Этот подход повышает безопасность, но не обеспечивает изоляцию.
Используйте "организацию" для представления арендатора продукта SaaS для достижения изоляции арендаторов
Ограничиваясь исключительно аутентификацией и авторизацией, нельзя будет предотвратить доступ пользователя с правильной ролью к ресурсам другого арендатора. Поэтому необходимо включить контекст "арендатора", например, ID арендатора, для ограничения доступа к ресурсам.
Вот тут и появляется необходимость изоляции арендаторов. Она использует идентификаторы, специфичные для арендаторов, для создания границ, подобных стенам, дверям и замкам, обеспечивая ясное разделение между арендаторами.
Управление идентичностями в многопользовательских приложениях
Мы обсудили изоляцию арендаторов, но как насчёт идентичностей? Как решать, нужно ли вам, чтобы ваши идентичности были "изолированными" или нет?
Часто существует путаница вокруг концепции "изоляции идентичности". Это может относиться к ситуациям, когда у одного пользователя реального мира есть две идентичности в общем понимании.
- Обе идентичности могут существовать в одной системе идентификации. Например, у Сары может быть личная электронная почта, зарегистрированная наряду с корпоративной, соединённой через единый вход (SSO).
- Пользователи сохраняют две различные идентичности в отдельных системах идентификации, представляющих абсолютно отдельные продукты. Эти продукты совершенно не связаны друг с другом.
Иногда эти сценарии называются "Изолированными идентичностями". Однако этот ярлык может не помочь в принятии решения.
Вместо того чтобы определять, нужна ли вам "изоляция идентичности", рассматривайте
Этот ответ может направить дизайн вашей системы. Для краткого ответа относительно многопользовательского приложения,
В многопользовательских приложениях идентичности, в отличие от ресурсов и данных, специфичных для арендаторов, разделяются среди нескольких арендаторов. Представьте себя администратором здания; вы, наверное, не захотели бы иметь два отдельных списка имен для управления идентичностями ваших арендаторов.
Когда стремитесь к изоляции арендаторов, вы могли заметить постоянный акцент на термин "организация", который часто считается лучшей практикой при создании многопользовательских приложений.
Используя понятие "организация", вы можете достичь изоляции арендаторов в своём многопользовательском приложении, сохраняя при этом единую систему идентификации.
Как выбрать и разработа ть соответствующую модель авторизации
При выборе правильной модели авторизации рассмотрите следующие вопросы:
- Вы разрабатываете продукт B2C, B2B или сочетание обоих типов?
- Есть ли у вашего приложения архитектура многопользовательского приложения?
- Существует ли необходимость в определённом уровне изоляции в вашем приложении, установленная бизнес-подразделением?
- Какие разрешения и роли нужно определить в контексте организации, а какие нет?
Какие разные модели авторизации доступны в Logto?
Контроль доступа на основе ролей (RBAC)
RBAC (Контроль доступа на основе ролей) — это метод предоставления пользователю разрешений на основе его ролей, позволяющий эффективно управлять доступом к ресурсам.
Эта общепринятая техника лежит в основ е контроля доступа и является ключевым компонентом функций авторизации Logto. Как всеобъемлющая платформа управления идентичностью, Logto предлагает специализированные решения для различных уровней и сущностей, обслуживая разработчиков и бизнес для разнообразных архитектур продуктов.
Контроль доступа к API на основе ролей
Чтобы защитить общие ресурсы API, которые не специфичны для какой-либо организации и не нуждаются в ограничениях контекста, функция API RBAC является идеальной.
Просто зарегистрируйте API и назначьте разрешения для каждого ресурса. Затем управляйте доступом через отношения между ролями и пользователями.
API ресурсы, роли и разрешения здесь "демократизированы" в рамках единой системы идентичности. Это довольно распространено в B2C продуктах с меньшей иерархией и не требует очень глубокого уровня изоляции.
Контроль доступа на основе ролей организации
В среде B2B и многопользовательской архитектуры изоляция арендаторов необходима. Для достижения этого организации используются как контекст для изоляции, что означает, что RBAC эффективен только тогда, когда пользователь принадлежит к определенной организации.
Организационный RBAC фокусируется на контроле доступа на уровне организации, а не на уровне API. Это обеспечивает значительную гибкость для самоорганизации на уровне организации в долгосрочной перспективе, но всё же в рамках единой системы идентичности.
Ключевой особенностью организации RBAC является то, что роли и разрешения, как правило, одинаковы для всех организаций по умолчанию, что делает "шаблон организации" Logto чрезвычайно значимым для повышения эффективности разработки. Это соответствует общей философии многопользовательских приложений, где политики контроля доступа и идентичности являются общими компонентами инфраструктуры для всех арендаторов (приложений арендаторов), что является распространённой практикой в продуктах SaaS.
Завершение
Эта статья предоставляет все, что вам нужно, чтобы начать подготовку и настройку многопользовательских приложений. Попробуйте Logto сегодня и начните применять лучшие практики для разработки многопользовательских приложений с использованием организаций.