Обзор настраиваемой политики Azure AD B2C

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

Настраиваемая политика полностью настраивается и управляется политикой. Настраиваемая политика управляет отношениями доверия между объектами в стандартных протоколах. Например, OpenID Connect, OAuth, SAML и несколько нестандартных, например межсистемный обмен заявками на основе REST API. Эта платформа обеспечивает удобные и доступные возможности для пользователей.

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

Начальный пакет настраиваемых политик

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

  • LocalAccounts позволяет использовать только локальные учетные записи.
  • SocialAccounts позволяет использовать только учетные записи социальных сетей (или федеративные).
  • SocialAndLocalAccounts позволяет использовать и локальные учетные записи, и учетные записи социальных сетей. Большинство наших образцов относятся к этой политике.
  • SocialAndLocalAccountsWithMFA позволяет использовать локальные учетные записи и учетные записи социальных сетей с многофакторной проверкой подлинности.

В репозитории GitHub с примерами для Azure AD B2C вы найдете примеры нескольких усовершенствованных путей взаимодействия с пользователем CIAM для Azure AD B2C. Например, усовершенствования политик локальных учетных записей, усовершенствования политик учетных записей социальной сети, усовершенствования MFA, усовершенствования пользовательского интерфейса, общие усовершенствования, миграция приложений, миграция пользователей, условный доступ, веб-тест и CI/CD.

Понимание основ

Утверждения

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

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

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

Управление утверждениями

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

Настройка и локализация пользовательского интерфейса

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

Чтобы настроить пользовательский интерфейс для вашего самопровозглашенного технического профиля, вы указываете URL-адрес в элементе определения содержания с настроенным содержанием HTML. В самостоятельно утвержденном техническом профиле вы указываете на этот идентификатор определения содержимого.

Чтобы настроить строки для конкретного языка, используйте элемент localization. Определение содержимого может содержать ссылку на локализацию, которая указывает список локализованных ресурсов для загрузки. Azure AD B2C объединяет элементы пользовательского интерфейса с содержимым HTML, загруженным по указанному URL-адресу, и отображает страницу для пользователя.

Обзор политики проверяющей стороны

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

Diagram showing the policy execution flow

Все приложения проверяющей стороны, использующие одну и ту же политику, получат одинаковые утверждения токенов, и пользователь пройдет один и тот же путь пользователя.

Пути взаимодействия пользователя

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

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

customized user journey

Шаги оркестрации

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

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

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

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

Azure AD B2C user journey

Технический профиль

Технический профиль предоставляет интерфейс для связи с разными типами сторон. Путь пользователя объединяет вызов технических профилей через шаги оркестровки для определения бизнес-логики.

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

Технический профиль проверки

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

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

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

Validation technical profile diagram

Модель наследования

Каждый начальный пакет включает следующие файлы:

  • Базовый файл, содержащий большую часть определений. Чтобы помочь с устранением неполадок и долгосрочным обслуживанием ваших политик, постарайтесь минимизировать количество изменений, которые вы вносите в этот файл.
  • Файл Локализация, содержащий строки локализации. Этот файл политики является производным от базового файла. Используйте этот файл для поддержки разных языков в соответствии с потребностями клиентов.
  • Файл расширений, содержащий уникальные изменения конфигурации для арендатора. Этот файл политики является производным от файла "Локализация". Он используется для добавления новых функциональных возможностей или переопределения существующих. Например, с его помощью можно реализовать федерацию с новыми поставщиками удостоверений.
  • Файл проверяющей стороны (RP) — файл с одной задачей, который вызывается непосредственно приложением проверяющей стороны, например веб-приложениями, мобильными или классическими приложениями. Для каждой уникальной задачи, такой как регистрация, вход в систему или изменение профиля, требуется собственный файл политики проверяющей стороны. Этот файл политики является производным от файла расширений.

Модель наследования выглядит следующим образом:

  • Дочерняя политика на любом уровне может наследоваться от родительской и расширять ее, добавляя новые элементы.
  • Для более сложных сценариев вы можете добавить больше уровней наследования (всего до 10).
  • Вы можете добавить больше политик проверяющей стороны. Например, удалить учетную запись, изменить номер телефона, политику проверяющей стороны SAML и многое другое.

На следующей схеме показана связь между файлами политики и приложениями проверяющей стороны.

Diagram showing the trust framework policy inheritance model

Руководство и рекомендации

Рекомендации

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

  • Создайте свою логику в рамках политики расширений или политики проверяющей стороны. Вы можете добавлять новые элементы, которые переопределят базовую политику, ссылаясь на тот же идентификатор. Этот подход позволит вам горизонтально увеличивать масштаб проекта и упростить обновление базовой политики позже, если корпорация Майкрософт выпустит новые начальные пакеты.
  • В рамках базовой политики настоятельно рекомендуется избегать внесения каких-либо изменений. При необходимости запишите комментарии, в которых вносятся изменения.
  • Когда вы переопределяете элемент, например метаданные технического профиля, избегайте копирования всего технического профиля из базовой политики. Вместо этого скопируйте только необходимый раздел элемента. См. Отключить подтверждение адреса электронной почты, чтобы узнать, как внести изменения.
  • Чтобы уменьшить дублирование технических профилей, в которых используются общие основные функции, используйте включение технических профилей.
  • Избегайте внесение записей в Azure Active Directory во время входа, поскольку это может привести к проблемам с регулированием.
  • Если ваша политика имеет внешние зависимости, такие как REST API, убедитесь, что они имеют высокую доступность.
  • Для повышения удобства работы пользователей убедитесь, что ваши пользовательские шаблоны HTML развернуты по всему миру с помощью доставки содержимого в сети. Сеть доставки содержимого Azure (CDN) позволяет сократить время загрузки, сэкономить полосу пропускания и повысить скорость ответа.
  • Если вы хотите изменить путь пользователя, скопируйте весь путь пользователя из базовой политики в политику расширения. Укажите уникальный идентификатор пути пользователя для скопированного пути пользователя. Затем в политике проверяющей стороны измените элемент путь пользователя по умолчанию, чтобы он указывал на новый путь пользователя.

Устранение неполадок

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

Непрерывная интеграция

Используя конвейер непрерывной интеграции и доставки (CI/CD), который вы настроили в Azure Pipelines, вы можете включить свои пользовательские политики Azure AD B2C в поставку программного обеспечения и автоматизацию управления кодом. При развертывании в различных средах Azure AD B2C, например в среде разработки, тестирования и производства, мы рекомендуем удалить ручные процессы и выполнить автоматическое тестирование с помощью Azure Pipelines.

Подготовка среды

Вы приступите к работе с настраиваемой политикой Azure AD B2C:

  1. Создание клиента Azure AD B2C
  2. Зарегистрируйте веб-приложение с помощью портала Azure, чтобы вы могли протестировать свою политику.
  3. Добавьте необходимые ключи политики и зарегистрируйте приложения Identity Experience Framework.
  4. Получите начальный пакет политики Azure AD B2C и загрузите его в свой клиент.
  5. После загрузки начального пакета проверьте свою политику регистрации или входа.
  6. Мы рекомендуем вам загрузить и установить Visual Studio Code (VS Code). Visual Studio Code представляет собой простой легкий, но мощный редактор исходного кода, который работает на вашем рабочем столе и доступен для Windows, macOS и Linux. С помощью VS Code вы можете быстро перемещаться по XML-файлам настраиваемой политики Azure AD B2C и редактировать их, установив расширение Azure AD B2C для VS Code

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

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