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

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

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

Дополнительные сведения о полных возможностях условного доступа см. в статье "Что такое условный доступ".

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

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

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

Типы приложений, затронутые

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

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

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

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

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

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

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

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

Microsoft Graph

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

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

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

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

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

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

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

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

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

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

Сценарии

Предпосылки

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

Рекомендации по конкретным сценариям

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

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

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

Сценарий. Приложение, выполняющее поток от имени

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

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

Идентификатор 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 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), вызывающее защищенный веб-API с условным доступом с помощью MSAL.js. Это простая архитектура, но имеет некоторые нюансы, которые необходимо учитывать при разработке вокруг условного доступа.

В 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, вызывающего веб-API Node.js с использованием потока от имени. В этом примере кода используется политика условного доступа и веб-API, зарегистрированные ранее в React SPA, для демонстрации этого сценария. В нем показано, как правильно обрабатывать вызов утверждений и получать маркер доступа, который можно использовать для веб-API.

См. также

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