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