Руководство разработчика по условному доступу Microsoft Entra

Функция условного доступа в идентификаторе Microsoft Entra предлагает один из нескольких способов защиты приложения и защиты службы. Условный доступ позволяет разработчикам и корпоративным клиентам защищать службы множеством способов, включая следующие.

• Многофакторная идентификация
• разрешение доступа к определенным службам только устройствам, зарегистрированным в Intune;
• ограничение расположения пользователей и диапазонов IP-адресов.

Сведения обо всех возможностях условного доступа см. в статье Что собой представляет условный доступ.

Для разработчиков, создающих приложения для идентификатора Microsoft Entra, в этой статье показано, как использовать условный доступ, и вы также узнаете о влиянии доступа к ресурсам, которые у вас нет контроля над тем, что могут применяться политики условного доступа. В статье рассматриваются последствия применения условного доступа в потоке On-Behalf-Of, веб-приложениях, а также при доступе к Microsoft Graph и вызове API.

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

Примечание.

Для использования этой функции требуется лицензия Microsoft Entra ID уровня P1. Чтобы найти подходящую лицензию, ознакомьтесь с разделом Сравнение общедоступных функций выпусков Free, Basic и Premium. Клиенты с лицензиями Microsoft 365 бизнес также имеют доступ к функциям условного доступа.

Как условный доступ влияет на приложения

Затронутые типы приложений

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

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

• приложения, выполняющие поток On-Behalf-Of;
• приложения, получающие доступ к нескольким службам или ресурсам;
• одностраничные приложения, использующие MSAL.js;
• веб-приложения, которые вызывают ресурс.

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

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

Примеры реализации условного доступа

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

• Вы создаете приложение iOS с одним клиентом и применяете политику условного доступа. В приложении выполняется вход пользователя и оно не запрашивает доступ к API. При входе пользователя политика автоматически вызывается, а пользователь должен выполнять многофакторную проверку подлинности (MFA).
• Вы создаете собственное приложение, использующее службу среднего уровня для доступа к нижестоящему API. Корпоративный клиент в организации, использующей это приложение, применяет политику к нисходящему API. Когда пользователь входит в систему, собственное приложение запрашивает доступ к среднему уровню и отправляет маркер. Средний уровень выполняет поток On-Behalf-Of для запроса доступа к нисходящему API. На этом этапе запрос утверждений передается на средний уровень. Средний уровень возвращает запрос собственному приложению, которое должно соответствовать политике условного доступа.

Microsoft Graph

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

В частности, все области Microsoft Graph представляют собой некоторый набор данных, к которому можно применить политики. Так как политики условного доступа назначаются определенным наборам данных, идентификатор Microsoft Entra применяет политики условного доступа на основе данных графа, а не самого Графа.

Например, если приложение запрашивает следующие области Microsoft Graph,

scopes="ChannelMessages.Read.All Mail.Read"

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

Соответствие политике условного доступа

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

Когда приложение пытается получить доступ к службе, для которой действует политика условного доступа, может возникнуть запрос условного доступа. Эта проблема закодирована в параметре claims , который поступает в ответ от идентификатора Microsoft Entra. Ниже приведен пример этого параметра запроса:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

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

Сценарии

Необходимые компоненты

Условный доступ Microsoft Entra — это функция, включенная в идентификатор Microsoft Entra ID P1 или P2. Клиенты с лицензиями Microsoft 365 бизнес также имеют доступ к функциям условного доступа.

Рекомендации для конкретных сценариев

Указанные сведения применимы только в следующих сценариях условного доступа:

• приложения, выполняющие поток On-Behalf-Of;
• приложения, получающие доступ к нескольким службам или ресурсам;
• одностраничные приложения, использующие MSAL.js;

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

Сценарий: приложение, в котором выполняется поток On-Behalf-Of

В этом сценарии рассматривается вариант, при котором собственное приложение вызывает веб-службу или API. Эта служба, в свою очередь, выполняет поток On-Behalf-Of для вызова подчиненной службы. В нашем случае применяется политика условного доступа к подчиненной службе (веб-API 2) и используется собственное приложение, а не серверное приложение или управляющая программа.

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

Идентификатор Microsoft Entra возвращает HTTP-ответ с некоторыми интересными данными:

Примечание.

В нашем примере это описание ошибки многофакторной проверки подлинности, но существует целый ряд ошибок interaction_required, которые могут быть связаны с условным доступом.

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

В веб-API 1 перехватывается ошибка error=interaction_required и отправляется запрос claims в классическое приложение. На этом этапе классическое приложение может сделать новый вызов acquireToken() и добавить запрос claims в качестве дополнительного параметра строки запроса. Этот новый запрос требует от пользователя выполнить многофакторную проверку подлинности, а затем отправить этот новый маркер обратно в веб-API 1 и завершить поток от имени.

Чтобы опробовать этот сценарий, см. пример кода .NET. Он демонстрирует передачу запроса утверждений из веб-API 1 в собственное приложение и создание запроса в клиентском приложении.

Сценарий: приложение, получающее доступ к нескольким службам

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

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

Кроме того, если приложение изначально запрашивает маркер для веб-службы A, пользователь не вызывает политику условного доступа. Это позволяет разработчику приложения контролировать взаимодействие с пользователем, чтобы политика условного доступа не вызывалась постоянно. Сложный случай заключается в том, что приложение позже запрашивает маркер для веб-службы B. На этом этапе конечный пользователь должен соответствовать политике условного доступа. Когда приложение пытается выполнить операцию acquireToken, может произойти следующая ошибка (как показано на схеме ниже):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Если приложение использует библиотеку MSAL, при сбое получения маркера всегда осуществляется повторная попытка в интерактивном режиме. Во время такого интерактивного запроса пользователь может выполнить условия условного доступа, но только если запрос не является AcquireTokenSilentAsync или PromptBehavior.Never, иначе приложение должно выполнить интерактивный запрос AcquireToken, чтобы пользователь мог обеспечить соответствие политике.

Сценарий: одностраничные приложения (SPA) с помощью MSAL.js

В этом сценарии рассматривается вариант, когда одностраничное приложение (SPA) использует MSAL.js для вызова защищенного условным доступом веб-API. Это простая архитектура с некоторыми особенностями, которые необходимо учитывать при реализации условного доступа.

В MSAL.js есть несколько функций получения маркеров: acquireTokenSilent(), acquireTokenPopup() и acquireTokenRedirect().

• acquireTokenSilent() может использоваться для автоматического получения маркера доступа. Это означает, что он никогда не будет отображаться на пользовательском интерфейсе.
• acquireTokenPopup() и acquireTokenRedirect() используются для автоматического запроса маркера для ресурса. Это означает, что они всегда отображаются на пользовательском интерфейсе входа.

Если приложению требуется маркер доступа для вызова веб-API, оно попробует выполнить функцию acquireTokenSilent(). Если срок действия маркера истек или необходимо обеспечить соответствие политике условного доступа, функция acquireToken завершится сбоем и приложение будет использовать acquireTokenPopup() или acquireTokenRedirect().

Давайте подробно рассмотрим пример со сценарием условного доступа. Пользователь только что зашел на веб-сайт и не имеет сеанса. Мы выполняем loginPopup() вызов, получаем маркер идентификатора без многофакторной проверки подлинности. Затем пользователь нажимает кнопку, которая требует от приложения запросить данные из веб-API. Приложение пытается выполнить вызов, но завершается сбоем acquireTokenSilent() , так как пользователь еще не выполнил многофакторную проверку подлинности и должен соответствовать политике условного доступа.

Идентификатор Microsoft Entra отправляет следующий HTTP-ответ:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

Приложению необходимо перехватить error=interaction_required. Приложение может использовать acquireTokenPopup() или acquireTokenRedirect() для того же ресурса. Пользователь вынужден выполнять многофакторную проверку подлинности. После завершения многофакторной проверки подлинности приложение выдает новый маркер доступа для запрошенного ресурса.

Чтобы попробовать этот сценарий, ознакомьтесь с нашим вызовом React SPA Node.js веб-API с помощью примера кода потока от имени. В этом примере кода используется политика условного доступа и веб-API, зарегистрированные ранее в React SPA, для демонстрации этого сценария. Он демонстрирует, как правильно обрабатывать запросы утверждений и получать маркер доступа, который может использоваться для веб-API.

См. также

• Дополнительные сведения о возможностях см. в разделе условный доступ в идентификаторе Microsoft Entra.
• Дополнительные примеры кода Microsoft Entra см . в примерах.
• Дополнительные сведения о пакетах SDK MSAL и доступе к справочной документации см. в обзоре библиотеки проверки подлинности Майкрософт.
• Дополнительные сведения о мультитенантных сценариях см. в статье "Как выполнить вход пользователей с помощью мультитенантного шаблона".
• Изучите статью Защита приложения SaaS IoT с помощью платформы удостоверений Майкрософт.