Поделиться через

Рекомендации по использованию Azure Active Directory B2C в мультитенантной архитектуре

  • Статья

Azure Active Directory (Azure AD) B2C предоставляет удостоверение для бизнеса в потребительскую службу. Удостоверение пользователя обычно является одним из основных аспектов при разработке мультитенантного приложения. Ваше решение удостоверений служит в качестве воротника для приложения, гарантируя, что ваши клиенты остаются в пределах границ, которые вы определяете для них. В этой статье описываются рекомендации и подходы к использованию Azure AD B2C в мультитенантном решении.

Одной из наиболее распространенных причин использования Azure AD B2C является включение федерации удостоверений для приложения. Федерация удостоверений — это процесс установления доверия между двумя поставщиками удостоверений, чтобы пользователи могли войти с помощью предварительно существующей учетной записи. Если вы используете Azure AD B2C, вы можете реализовать федерацию удостоверений, чтобы пользователи могли войти с помощью социальных или корпоративных учетных записей. Если вы используете федерацию, пользователям не нужно создавать отдельную локальную учетную запись , относящуюся к приложению.

Если вы не знакомы с этим разделом, рекомендуем ознакомиться со следующими ресурсами:

Примечание.

В этой статье рассматриваются два аналогичных именованных понятия: клиенты приложений и клиенты Azure AD B2C.

Термин "клиент приложения" используется для ссылки на ваши клиенты, которые могут быть вашими клиентами или группами пользователей.

Azure AD B2C также использует концепцию клиента в ссылке на отдельные каталоги, а термин мультитенантности используется для обращения к взаимодействию между несколькими клиентами Azure AD B2C. Хотя термины одинаковы, понятия не являются. Когда клиент Azure AD B2C ссылается на эту статью, используется полный срок использования клиента Azure AD B2C.

Идентификация в мультитенантных решениях

В мультитенантных решениях часто объединяет несколько служб удостоверений для достижения различных наборов требований. Многие решения имеют два различных набора удостоверений:

  • Удостоверения клиентов, которые предназначены для учетных записей конечных пользователей. Они управляют тем, как пользователи клиентов получают доступ к вашим приложениям.
  • Внутренние удостоверения, которые обрабатывают управление решением вашей команды.

Эти различные типы удостоверений также обычно используют отдельные службы удостоверений. Azure AD B2C — это служба управления удостоверениями клиентов и доступом (CIAM), которую пользователи клиентов используют для доступа к решению. Идентификатор Microsoft Entra — это служба управления удостоверениями и доступом (IAM), которую вы и ваша команда используют для управления ресурсами Azure и управления приложением.

Рассмотрим пример мультитенантного решения, созданного Fabrikam. Решение использует сочетание двух служб для удовлетворения требований Fabrikam:

  • Fabrikam реализует Azure AD B2C, чтобы клиенты компании (клиенты) могли войти в приложения.
  • Сотрудники Fabrikam используют каталог Microsoft Entra своей организации для получения доступа к решению в целях управления и администрирования. Они используют те же удостоверения, что и для доступа к другим ресурсам Fabrikam, таким как Microsoft Office.

Этот пример представлен на схеме ниже.

Схема, изображающая два приложения с двумя методами входа.

Модели изоляции

При использовании Azure AD B2C необходимо решить, как изолировать учетные записи пользователей между разными клиентами приложения.

Вам нужно рассмотреть такие вопросы:

  • Необходимо ли федеративные входы в поставщики удостоверений клиента? Например, необходимо включить федерацию SAML, Microsoft Entra ID, поставщиков социальных входов или других источников?
  • У вас или ваших клиентов есть требования к месту размещения данных?
  • Требуется ли пользователю доступ к нескольким клиентам приложений?
  • Требуются ли сложные разрешения и (или) управление доступом на основе ролей (RBAC)?
  • Кто входит в приложение? Различные категории пользователей часто называются пользователями.

В следующей таблице перечислены различия между основными моделями аренды для Azure AD B2C:

Фактор Общий клиент Azure AD B2C Клиент Azure AD B2C с вертикальной секционированием Один клиент Azure AD B2C для каждого клиента приложения
Изоляция данных Данные из каждого клиента приложения хранятся в одном клиенте Azure AD B2C, но к ним могут обращаться только администраторы. Данные из каждого клиента приложения распределяются между несколькими клиентами Azure AD B2C, но доступ к ним осуществляется только администраторами. Данные из каждого клиента приложения хранятся в выделенном клиенте Azure AD B2C, но к ним могут обращаться только администраторы.
Сложность развертывания Низкая Средний и высокий, в зависимости от стратегии секционирования Крайне высоко
Ограничения для рассмотрения Запросы на клиент Azure AD B2C, запросы на IP-адрес клиента Сочетание запросов, количество клиентов Azure AD B2C на подписку и количество каталогов для одного пользователя в зависимости от стратегии секционирования Число клиентов Azure AD B2C на подписку, максимальное количество каталогов для одного пользователя
Операционная сложность Низкая Средний и высокий, в зависимости от стратегии секционирования Крайне высоко
Количество необходимых клиентов Azure AD B2C Единица Между одной и n в зависимости от стратегии секционирования n, где n — число клиентов приложения
Пример сценария Вы создаете предложение SaaS для потребителей, которые имеют низкие или нет требований к месту размещения данных, таких как служба потоковой передачи музыки или видео. Вы создаете предложение SaaS, например учетную запись и хранение приложений для бизнеса. Необходимо поддерживать требования к месту размещения данных или большое количество пользовательских федеративных поставщиков удостоверений. Вы создаете предложение SaaS, например приложение для государственных организаций. Клиенты могут обеспечить высокую степень изоляции данных от других клиентов приложений.

Общий клиент Azure AD B2C

Как правило, проще всего управлять одним общим клиентом Azure AD B2C, если ваши требования позволяют ему. Вам нужно поддерживать только один клиент в долгосрочной перспективе, и этот параметр создает наименьшие затраты.

Примечание.

Рекомендуется использовать общий клиент Azure AD B2C для большинства сценариев.

Вы должны рассмотреть общий клиент Azure AD B2C, когда:

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

На этой схеме показана общая модель клиента Azure AD B2C:

Схема, на которой показаны три приложения, подключающиеся к одному общему клиенту Azure AD B2C.

Клиенты Azure AD B2C с вертикальной секционированием

Подготовка клиентов Azure AD B2C по вертикали — это стратегия, предназначенная для минимизации числа клиентов Azure AD B2C. Это среднее место между другими моделями аренды. Вертикальное секционирование обеспечивает большую гибкость при настройке для конкретных клиентов, если это необходимо. Однако она не создает операционные издержки, связанные с подготовкой клиента Azure AD B2C для каждого клиента приложения.

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

Вертикальное секционирование аналогично шаблону сегментирования данных. Чтобы вертикально секционировать арендаторы Azure AD B2C, необходимо упорядочить арендаторы приложения в логические группы. Эта классификация клиентов часто называется стратегией секционирования. Стратегия секционирования должна основываться на общем, стабильном факторе клиента приложения, например региона, размера или пользовательских требований клиента приложения. Например, если ваша цель заключается в решении требований к месту расположения данных, вы можете решить развернуть клиент Azure AD B2C для каждого региона, в котором размещаются клиенты приложений. Или, если вы группируете по размеру, вы можете решить найти большинство удостоверений клиентов приложений в одном клиенте Azure AD B2C, но найти крупнейшие клиенты приложений на своих собственных выделенных клиентах Azure AD B2C.

Внимание

Избегайте базирования стратегии секционирования на факторах, которые могут меняться с течением времени, так как трудно перемещать пользователей между клиентами Azure AD B2C. Например, если вы создаете предложение SaaS с несколькими номерами SKU или уровнями продуктов, вы не должны секционировать пользователей на основе выбранного номера SKU, так как номер SKU может измениться, если клиент обновляет свой продукт.

Следует рассмотреть возможность подготовки клиентов Azure AD B2C с помощью вертикально секционированных стратегий, если:

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

На следующей схеме показана вертикально секционированная модель клиента Azure AD B2C:

Схема с тремя приложениями. Два подключены к общему клиенту Azure AD B2C. Третий связан с собственным клиентом Azure AD B2C.

Один клиент Azure AD B2C для каждого клиента приложения

При подготовке клиента Azure AD B2C для каждого клиента приложения можно настроить множество факторов для каждого клиента. Однако этот подход создает значительное увеличение затрат. Необходимо разработать стратегию развертывания и обслуживания для потенциально большого количества клиентов Azure AD B2C.

Кроме того, необходимо учитывать ограничения служб. Подписки Azure позволяют развертывать только ограниченное количество клиентов Azure AD B2C. Если вам нужно развернуть больше, чем разрешено, необходимо рассмотреть соответствующую структуру подписки, чтобы сбалансировать арендаторы Azure AD B2C в нескольких подписках. Существуют и другие ограничения Microsoft Entra, которые также применяются, например количество каталогов, к которым может создавать один пользователь, и количество каталогов, к которым может принадлежать пользователь.

Предупреждение

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

Распространенное заблуждение заключается в том, что при использовании шаблона меток развертывания необходимо включить службы удостоверений в каждую метку. Это не обязательно верно, и вместо этого можно использовать другую модель изоляции. Упражнение по усердию и четкое бизнес-обоснование, если вы используете эту модель изоляции. Затраты на развертывание и обслуживание являются значительными.

Следует рассмотреть возможность подготовки клиента Azure AD B2C для каждого клиента приложения, только если:

  • У вас есть строгие требования к изоляции данных для клиентов приложений.
  • У вас есть долгосрочная стратегия развертывания и обслуживания большого количества клиентов Azure AD B2C.
  • У вас есть стратегия сегментирования клиентов между одной или несколькими подписками Azure для соблюдения ограничения на клиент Azure AD B2C для каждого клиента.
  • Ваше приложение или может быть известно о мультитенантности и знает, в какой клиент Azure AD B2C необходимо войти в систему.
  • Необходимо выполнить настраиваемую настройку для каждого клиента приложения.
  • Пользователям не нужно обращаться к нескольким клиентам приложения с помощью одной учетной записи входа.

На следующей схеме показано использование одного клиента Azure AD B2C для каждого клиента приложения:

Схема, показывающая три приложения, каждый из которых подключается к собственному клиенту Azure AD B2C.

Федерация удостоверений

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

Федерацию удостоверений можно также использовать в качестве средства для управления несколькими клиентами Azure AD B2C, федеративными клиентами Azure AD B2C друг с другом. Это позволяет приложению доверять одному клиенту Azure AD B2C. Приложению не нужно знать, что клиенты разделены между несколькими клиентами Azure AD B2C. Этот подход чаще всего используется в модели изоляции с вертикальной секционированием, когда пользователи секционируются по регионам. При принятии этого подхода необходимо учитывать некоторые соображения. Общие сведения об этом подходе см. в разделе "Глобальные решения идентификации".

Обнаружение домашней области

Обнаружение домашней области — это процесс автоматического выбора федеративного поставщика удостоверений для события входа пользователя. Если вы автоматически выбираете поставщика удостоверений пользователя, вам не нужно запрашивать у пользователя выбор поставщика.

Обнаружение домашней области важно при использовании общего клиента Azure AD B2C, а также позволяет клиентам использовать собственный федеративный поставщик удостоверений. Может потребоваться избежать проектирования, в котором пользователю необходимо выбрать из списка поставщиков удостоверений. Это упрощает процесс входа. Кроме того, пользователь может случайно выбрать неверный поставщик, что приводит к сбою попытки входа.

Обнаружение домашней области можно настроить различными способами. Наиболее распространенным подходом является использование суффикса домена адреса электронной почты пользователя для определения поставщика удостоверений. Например, скажем, Northwind Traders является клиентом мультитенантного решения Fabrikam. Адрес user@northwindtraders.com электронной почты содержит суффикс northwindtraders.comдомена, который можно сопоставить с поставщиком федеративных удостоверений Northwind Traders.

Дополнительные сведения см. в разделе "Обнаружение домашней области". Пример реализации этого подхода в Azure AD B2C см . в репозитории GitHub примеров Azure AD B2C.

Место расположения данных

При подготовке клиента Azure AD B2C выберите для назначения расположения данных регион, в котором будет развернут клиент. Этот выбор важен, так как он указывает регион, в котором хранятся данные клиента при хранении. Если у вас есть требования к месту расположения данных для подмножества клиентов, рассмотрите возможность использования вертикально секционированных стратегий.

Авторизация

Для надежного решения идентификации необходимо рассмотреть возможность авторизации в дополнение к проверке подлинности. Существует несколько подходов к использованию платформа удостоверений Майкрософт для создания стратегии авторизации для приложения. В примере AppRoles показано, как использовать роли приложений Azure AD B2C для реализации авторизации в приложении. В нем также описываются альтернативные подходы к авторизации.

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

Обслуживание

При планировании мультитенантного развертывания Azure AD B2C необходимо думать о долгосрочном обслуживании ресурсов Azure AD B2C. Клиент Azure AD B2C, такой как клиент Microsoft Entra организации, является ресурсом, который необходимо создать, поддерживать, работать и защищать. Хотя следующий список не является исчерпывающим, следует рассмотреть расходы на обслуживание в таких областях:

  • Управление клиентом. Кто поддерживает клиент Azure AD B2C? Какие роли с повышенными привилегиями требуются этим администраторам? Как настроить политики условного доступа и MFA для администраторов? Как отслеживать клиент Azure AD B2C в долгосрочной перспективе?
  • Конфигурация пути пользователя. Как развернуть изменения в клиенте или клиентах Azure AD B2C? Как протестировать изменения в потоках пользователей или пользовательских политиках перед их развертыванием?
  • Федеративные поставщики удостоверений. Необходимо ли добавлять или удалять поставщиков удостоверений с течением времени? Если вы разрешаете каждому из клиентов использовать собственный поставщик удостоверений, как управлять этим в масштабе?
  • Регистрация приложений. Многие регистрации приложений Microsoft Entra используют секрет клиента или сертификат для проверки подлинности. Как изменить эти секреты или сертификаты при необходимости?
  • Ключи политики. Если вы используете пользовательские политики, как повернуть ключи политики, когда нужно?
  • Учетные данные пользователя. Как управлять сведениями пользователей и учетными данными? Что произойдет, если один из ваших пользователей заблокирован или забыл пароль и требует вмешательства администратора или службы клиентов?

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

Развертывания и DevOps

Хорошо определенный процесс DevOps поможет свести к минимуму затраты, необходимые для обслуживания клиентов Azure AD B2C. В начале процесса разработки следует реализовать методики DevOps. В идеале необходимо попытаться автоматизировать все или большинство задач обслуживания, включая развертывание изменений в пользовательских политиках или потоках пользователей. Необходимо также спланировать создание нескольких клиентов Azure AD B2C для постепенного тестирования изменений в более низких средах перед развертыванием в рабочих клиентах. Конвейеры DevOps могут выполнять эти действия по обслуживанию. API Microsoft Graph можно использовать для программного управления клиентами Azure AD B2C.

Дополнительные сведения об автоматизированных развертываниях и управлении Azure AD B2C см. в следующих ресурсах.

Внимание

Некоторые конечные точки, которые используются для управления Azure AD B2C программным способом, недоступны. API-интерфейсы в бета-версии Microsoft Graph могут изменяться в любое время и подлежат предварительному выпуску условий обслуживания.

Сравнение Microsoft Entra B2B с Azure AD B2C

Совместная работа Microsoft Entra B2B — это функция Внешняя идентификация Microsoft Entra, которую можно использовать для приглашения гостевых пользователей в клиент Microsoft Entra организации для совместной работы с ними. Как правило, вы используете совместную работу B2B, если необходимо предоставить внешнему пользователю, например поставщику, доступ к ресурсам в клиенте Microsoft Entra.

Azure AD B2C — это уникальный продукт, отличный от Внешняя идентификация Microsoft Entra, который предоставляет другой набор функций. Azure AD B2C предназначен для использования клиентами вашего продукта. Клиент Azure AD B2C отличается от вашего клиента Microsoft Entra организации.

В зависимости от пользователей и сценариев может потребоваться использовать Microsoft Entra B2B, Azure AD B2C или даже одновременно. Например, если ваше приложение должно пройти проверку подлинности нескольких типов пользователей, таких как сотрудники организации, пользователи, работающие для поставщика и клиентов, все в одном приложении, можно использовать Microsoft Entra B2B и Azure AD B2C вместе для удовлетворения этого требования.

Дополнительные сведения см. в разделе:

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги