Руководство для разработчиков по контексту проверки подлинности Условный доступ

Применяется к: зеленый круг с символом белой галочки, указывающим следующее содержимое, применимое к клиентам рабочей силы. Клиенты рабочей силы Внешние клиенты (дополнительные сведения)

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

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

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

Формулировка проблемы

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

Итак, что делать, если приложения смогли смешивать оба? Работа с более низким уровнем безопасности и меньшим количеством запросов для большинства сценариев. Затем условное повышение требований безопасности при доступе к более конфиденциальным данным?

Распространенные сценарии

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

Предварительные требования

Во-первых, приложение должно быть интегрировано с платформой идентификации Microsoft с помощью протоколов OpenID Connect/ OAuth 2.0 для проверки подлинности и авторизации. Мы рекомендуем использовать библиотеки аутентификации платформа удостоверений Майкрософт для интеграции и защиты вашего приложения с помощью Microsoft Entra ID. Документация по платформе удостоверений Майкрософт — хорошее место, чтобы начать изучать интеграцию ваших приложений с платформой удостоверений Майкрософт. Поддержка функции контекста аутентификации условного доступа построена на основе расширений протокола, предоставляемых стандартным отраслевым протоколом OpenID Connect. Разработчики используют ссылку контекста проверки подлинности условного доступазначение с параметром запрос утверждений, чтобы дать приложениям возможность запускать и выполнять политику.

Во-вторых, Условный доступ требует лицензии Microsoft Entra ID P1. Дополнительные сведения о лицензировании можно найти на странице ценообразования Microsoft Entra.

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

Этапы интеграции

Эту функцию можно интегрировать в приложения после интеграции с помощью поддерживаемых протоколов проверки подлинности и регистрации в клиенте Microsoft Entra с доступным компонентом условного доступа.

Примечание

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

Во-первых, объявите и сделайте контексты проверки подлинности доступными в арендаторе. Дополнительные сведения см. в разделе Настройка контекстов проверки подлинности.

Значения C1-C99 доступны для использования в качестве идентификаторов контекста проверки подлинности в арендаторе. Примерами контекста проверки подлинности могут быть:

C1 - Требовать строгую аутентификацию
C2 – Требуются совместимые устройства
C3 – Требовать доверенные расположения

Чтобы использовать контексты проверки подлинности условного доступа, создайте или измените политики условного доступа. Примеры политик могут быть следующими:

Все пользователи, выполнив вход в это веб-приложение, должны успешно завершить 2FA для идентификатора контекста проверки подлинности C1.
Все пользователи, входящие в это веб-приложение, должны успешно пройти 2FA, а также иметь доступ к приложению из заданного диапазона IP-адресов для идентификатора контекста проверки подлинности C3.

Примечание

Значения контекста аутентификации условного доступа объявляются и поддерживаются отдельно от приложений. Не рекомендуется, чтобы приложения имели жёсткую зависимость от идентификаторов контекста аутентификации. ИТ-администраторы обычно создают политики условного доступа, так как они имеют лучшее представление о доступных ресурсах. Точно так же, если приложение используется в нескольких арендаторах, то могут быть использованы разные идентификаторы контекста аутентификации, а в некоторых случаях они будут и вовсе недоступными.

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

Действия идентификации в коде, которые можно сделать доступными для сопоставления с ID контекста аутентификации.
Создайте экран на портале администрирования приложения (или аналогичную функциональность), который ИТ-администраторы могут использовать для сопоставления конфиденциальных действий с доступным для использования ID контекста аутентификации.
Пример кода см. в разделе Использование контекста проверки подлинности для условного доступа для выполнения усиленной проверки подлинности.

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

Запросите MS Graph, чтобы перечислить все доступные контексты проверки подлинности.
Разрешить ИТ-администраторам выбирать конфиденциальные или высокопривилегированные операции и назначать их доступным контекстам аутентификации с помощью политик условного доступа.
Сохранить эти сведения о сопоставлении в базе данных или локальном хранилище.

Настройка потока для создания контекста проверки подлинности

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

В ходе операции в конфиденциальном и защищённом auth-контексте оцените значения в утверждении acrs с ранее сохранёнными сопоставлениями ID контекста аутентификации и вызовите Claims Challenge, как показано в следующем фрагменте кода.

На следующей схеме показано взаимодействие между пользователем, клиентским приложением и веб-API.

Схема взаимодействия пользователя, веб-приложения, API и Microsoft Entra ID

Приведенный ниже фрагмент кода взят из примера кода Использование контекста проверки подлинности условного доступа для выполнения проверки подлинности повышенного уровня. Первый метод — CheckForRequiredAuthContext() в API

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

public void CheckForRequiredAuthContext(string method)
{
    string authType = _commonDBContext.AuthContext.FirstOrDefault(x => x.Operation == method
                && x.TenantId == _configuration["AzureAD:TenantId"])?.AuthContextId;

    if (!string.IsNullOrEmpty(authType))
    {
        HttpContext context = this.HttpContext;
        string authenticationContextClassReferencesClaim = "acrs";

        if (context == null || context.User == null || context.User.Claims == null
            || !context.User.Claims.Any())
        {
            throw new ArgumentNullException("No Usercontext is available to pick claims from");
        }

        Claim acrsClaim = context.User.FindAll(authenticationContextClassReferencesClaim).FirstOrDefault(x
            => x.Value == authType);

        if (acrsClaim == null || acrsClaim.Value != authType)
        {
            if (IsClientCapableofClaimsChallenge(context))
            {
                string clientId = _configuration.GetSection("AzureAd").GetSection("ClientId").Value;
                var base64str = Convert.ToBase64String(Encoding.UTF8.GetBytes("{\"access_token\":{\"acrs\":{\"essential\":true,\"value\":\"" + authType + "\"}}}"));

                context.Response.Headers.Append("WWW-Authenticate", $"Bearer realm=\"\", authorization_uri=\"https://login.microsoftonline.com/common/oauth2/authorize\", client_id=\"" + clientId + "\", error=\"insufficient_claims\", claims=\"" + base64str + "\", cc_type=\"authcontext\"");
                context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
                string message = string.Format(CultureInfo.InvariantCulture, "The presented access tokens had insufficient claims. Please request for claims requested in the WWW-Authentication header and try again.");
                context.Response.WriteAsync(message);
                context.Response.CompleteAsync();
                throw new UnauthorizedAccessException(message);
            }
            else
            {
                throw new UnauthorizedAccessException("The caller does not meet the authentication  bar to carry our this operation. The service cannot allow this operation");
            }
        }
    }
}

Примечание

Формат запроса утверждений описан в статье "Запрос утверждений на платформе идентификации Microsoft".

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

internal static string ExtractHeaderValues(WebApiMsalUiRequiredException response)
{
    if (response.StatusCode == System.Net.HttpStatusCode.Unauthorized && response.Headers.WwwAuthenticate.Any())
    {
        AuthenticationHeaderValue bearer = response.Headers.WwwAuthenticate.First(v => v.Scheme == "Bearer");
        IEnumerable<string> parameters = bearer.Parameter.Split(',').Select(v => v.Trim()).ToList();
        var errorValue = GetParameterValue(parameters, "error");

        try
        {
            // read the header and checks if it contains error with insufficient_claims value.
            if (null != errorValue && "insufficient_claims" == errorValue)
            {
                var claimChallengeParameter = GetParameterValue(parameters, "claims");
                if (null != claimChallengeParameter)
                {
                    var claimChallenge = ConvertBase64String(claimChallengeParameter);

                    return claimChallenge;
                }
            }
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
    return null;
}

Обработайте исключение в вызове веб-API; если представлен запрос claims challenge, перенаправьте пользователя обратно в Microsoft Entra ID для дальнейшей обработки.

try
{
    // Call the API
    await _todoListService.AddAsync(todo);
}
catch (WebApiMsalUiRequiredException hex)
{
    // Challenges the user if exception is thrown from Web API.
    try
    {
        var claimChallenge =ExtractHeaderValues(hex);
        _consentHandler.ChallengeUser(new string[] { "user.read" }, claimChallenge);

        return new EmptyResult();
    }
    catch (Exception ex)
    {
        _consentHandler.HandleException(ex);
    }

    Console.WriteLine(hex.Message);
}
return RedirectToAction("Index");

(Необязательно) Объявите возможность клиента. Клиентские возможности помогают поставщикам ресурсов (RP), таким как наш веб-API, обнаруживать, понимает ли клиентское приложение вызов утверждений и может соответствующим образом настроить ответ. Эта возможность может быть полезной, если не все клиенты API способны обрабатывать запросы claim challenge, а некоторые старые клиенты по-прежнему ожидают другого ответа. Дополнительные сведения см. в разделе Возможности клиента.

Предостережения и рекомендации

Не прописывайте значения Auth Context в коде приложения жестко. Приложения должны читать и применять контекст аутентификации с помощью вызовов MS Graph. Эта практика очень важна для мультитенантных приложений. Значения контекста проверки подлинности зависят от клиентов Microsoft Entra и недоступны в выпуске Microsoft Entra ID Free. Дополнительные сведения о том, как приложение должно запрашивать, задавать и использовать контекст проверки подлинности в коде, см. в примере кода, используйте контекст проверки подлинности условного доступа для выполнения проверки подлинности на шаге.

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

Примеры кода

Контекст аутентификации [ACRs] — ожидаемое поведение условного доступа

Явное выполнение требований контекста аутентификации в запросах

Клиент может явно запрашивать токен с контекстом проверки подлинности (ACRS) через утверждения в теле запроса. Если ACRS был запрошен, условный доступ разрешает выдачу токена с запрошенным ACRS, если все требования были выполнены.

Ожидаемое поведение, если контекст проверки подлинности не защищен Условным доступом в тенанте

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

Сводная таблица для ожидаемого поведения при явном запросе ACRS

Запрошено ACRS	Политика применена	Проверка пройдена	ACRS добавлен в заявки
Да	нет	Да	Да
Да	Да	нет	нет
Да	Да	Да	Да
Да	Нет политик, настроенных с помощью ACRS	Да	Да

Неявное удовлетворение требований контекста аутентификации за счёт оппортунистической проверки

Поставщик ресурсов может включить необязательное утверждение "acrs". Условный доступ пытается оппортунистически добавить ACRS в утверждения токена, чтобы избежать дополнительных обращений для получения новых токенов для Microsoft Entra ID. В этой оценке Условный доступ проверяет, удовлетворены ли политики, защищающие запросы контекста проверки подлинности, и добавляет ACRS в утверждения токена, если это так.

Примечание

Каждый тип токена (ID токен, токен доступа) необходимо включать отдельно.

Если поставщик ресурсов не выбирает опциональное утверждение 'acrs', единственным способом получения 'acrs' в токене является явный запрос в запросе токена. Он не получит преимущества от оппортунистической оценки, поэтому каждый раз, когда необходимый ACRS отсутствует в утверждениях токена, поставщик ресурсов запрашивает у клиента новый токен, включающий его в свои утверждения.

Ожидаемое поведение с контекстом проверки подлинности и элементами управления сеансами для неявной оппортунистической оценки ACRS

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

Cloud App Security (CAS)

Условный доступ считает управление сеансом CAS выполненным для оценки opportunistic ACRS, когда сеанс CAS был установлен во время данного запроса. Например, когда поступает запрос и применяется любая политика условного доступа, которая приводит к принудительному запуску сеанса CAS, и есть ещё одна политика условного доступа, которая также требует сеанса CAS, то поскольку сеанс CAS будет принудительно применён, это удовлетворяет требованиям управления сеансом CAS для оппортунистической оценки.

Ожидаемое поведение, когда арендатор содержит политики условного доступа, защищающие контекст проверки подлинности

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

Политика A: Требовать многофакторную аутентификацию для всех пользователей, за исключением пользователя "Ариэль", при запросе "c1" acrs. Политика B: блокировать всех пользователей, за исключением пользователя "Jay", при запросе "c2" или "c3" ACR.

Поток	Запрошено ACRS	Политика применена	Проверка пройдена	ACRS добавлено в претензии
Ariel запрашивает токен доступа	c1	Нет	Да, для "c1". Нет для "c2" и "c3"	"c1" (запрошено)
Ариэль запрашивает маркер доступа	"c2"	Политика «Б»	Заблокировано политикой B	Нет
Ariel запрашивает токен доступа	Нет	Нет	Да, для «c1». Нет для "c2" и "c3"	"c1" (добавлен при возможности из политики A)
Jay запрашивает токен доступа (без MFA)	c1	Политика А	нет	Нет
Jay запрашивает токен доступа (с MFA)	c1	Политика A	Да	"c1" (запрошено), "c2" (оппортунистически добавлен из политики B), "c3" (оппортунистически добавлен из политики B)
Jay запрашивает токен доступа (без MFA)	"c2"	Нет	Да для "c2" и "c3". Нет, "c1"	"c2" (запрошено), "c3" (оппортунистически добавлен из политики B)
Jay запрашивает токен доступа (с MFA)	"c2"	Нет	Да для "c1", "c2" и "c3"	"c1" (по возможности со стороны A), "c2" (запрошено), "c3" (добавлен при наличии возможности согласно политике B)
Jay запрашивает токен доступа (с MFA)	Нет	Нет	Да для "c1", "c2" и "c3"	"c1", "c2", "c3" все были добавлены по возможности
Jay запрашивает токен доступа (без MFA)	Нет	Нет	Да, для "c2" и "c3". Нет "c1"	"c2", "c3" все были добавлены при наличии возможности

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

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2026-10-08

Руководство для разработчиков по контексту проверки подлинности Условный доступ

Формулировка проблемы

Распространенные сценарии

Предварительные требования

Этапы интеграции

Предостережения и рекомендации

Примеры кода

Контекст аутентификации [ACRs] — ожидаемое поведение условного доступа

Явное выполнение требований контекста аутентификации в запросах

Ожидаемое поведение, если контекст проверки подлинности не защищен Условным доступом в тенанте

Сводная таблица для ожидаемого поведения при явном запросе ACRS

Неявное удовлетворение требований контекста аутентификации за счёт оппортунистической проверки

Ожидаемое поведение с контекстом проверки подлинности и элементами управления сеансами для неявной оппортунистической оценки ACRS

Частота входа по интервалам

Cloud App Security (CAS)

Ожидаемое поведение, когда арендатор содержит политики условного доступа, защищающие контекст проверки подлинности

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

Обратная связь

Дополнительные ресурсы