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

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

Настраиваемые политики можно в полной мере изменять и администрировать на основе политик. Настраиваемая политика управляет отношениями доверия между объектами в стандартных протоколах. Например, OpenID Подключение, 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 известно как поставщик услуг, вызывает политику проверяющей стороны для выполнения определенного пути. Политика проверяющей стороны определяет путь, который необходимо выполнить, и список утверждений, которые содержит маркер.

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

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

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

В приведенных ниже инструкциях содержаться сведения о том, как добавить шаги оркестрации в политику стартового пакета учетных записей социальной сети и локальных учетных записей. Ниже приведен пример добавленного вызова 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, как понять, как создать и запустить собственные пользовательские политики в серии руководств.