Обзор настраиваемой политики 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-содержимым. В самоутверждающем техническом профиле указываете на этот идентификатор определения контента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Интегрируйте Application Insights с Azure AD B2C для диагностики исключений.
• Расширение Azure AD B2C для Visual Studio Code поможет вам получить доступ к журналам и визуализировать их на основе имени политики и времени.
• Наиболее распространенная ошибка при настройке пользовательских политик — это неправильное форматирование XML. Используйте проверку схемы XML для выявления ошибок перед отправкой XML-файла.

Используя конвейер непрерывной интеграции и доставки (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 можно начать настройку политики. Ознакомьтесь со следующими статьями, чтобы узнать, как:

• Добавьте утверждения и настройте входные данные пользователей с помощью пользовательских политик. Узнайте, как определить утверждение и добавить утверждение в пользовательский интерфейс, настроив некоторые технические профили начального пакета.
• Настройте пользовательский интерфейс приложения с помощью пользовательской политики. Узнайте, как создать собственное HTML-содержимое и настроить определение контента.
• Локализация пользовательского интерфейса приложения с помощью пользовательской политики. Узнайте, как настроить список поддерживаемых языков и предоставить метки, относящиеся к языку, добавив локализованный элемент ресурсов.
• Во время разработки и тестирования политики можно отключить проверку электронной почты. Узнайте, как перезаписать метаданные технического профиля.
• Настройте вход с помощью учетной записи Google с помощью пользовательских политик. Узнайте, как создать новый поставщик утверждений с помощью технического профиля OAuth2. Затем настройте путешествие пользователя, чтобы включить параметр входа в Google.
• Чтобы диагностировать проблемы с настраиваемыми политиками, вы можете собирать журналы Azure Active Directory B2C с помощью Application Insights. Узнайте, как добавить новые технические профили и настроить политику доверяющей стороны.
• Если вы хотите понять, как с нуля создается настраиваемая политика, узнайте, как создавать и запускать собственные настраиваемые политики в серии руководств по Azure Active Directory B2C.