Рекомендации разработчиков по контексту проверки подлинности Условного доступа

Статья
10/24/2023

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

C1. Требование строгой проверки подлинности.
C2. Требование соответствующих устройств.
C3. Требование надежных расположений.

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

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

Примечание.

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

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

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

Эти шаги представляют собой изменения, которые необходимо внести в кодовую базу. Для этого нужно:

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

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

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

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

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

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

Приведенный ниже фрагмент кода взят из примера кода Использование контекста проверки подлинности Условного доступа для выполнения проверки подлинности повышенного уровня. Первый метод, 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 Entra для дальнейшей оценки политики. Приведенный ниже фрагмент кода взят из примера кода Использование контекста проверки подлинности Условного доступа для выполнения проверки подлинности повышенного уровня.

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, если представлена проблема утверждений, перенаправьте пользователя обратно в идентификатор Microsoft Entra для дальнейшей обработки.

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");

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

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

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

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

Примеры кода

Контекст проверки подлинности [AR] в ожидаемом поведении условного доступа

Явное удовлетворение контекста проверки подлинности в запросах

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

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

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

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

Запрошено ACRS	Примененная политика	Контроль удовлетворен	ACRS добавлено в утверждения
Да	No	Да	Да
Да	Да	No	No
Да	Да	Да	Да
Да	Политики, настроенные с помощью ACRS, не настроены	Да	Да

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

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

Примечание.

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

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

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

Условный доступ рассматривает "частоту входа по интервалу" как удовлетворенную для оценки оппортунистических ACRS, когда все эти факторы проверки подлинности находятся в пределах интервала частоты входа. В случае, если первый момент проверки подлинности фактора является устаревшим, или если второй фактор (MFA) присутствует, а его момент проверки подлинности является устаревшим, частота входа по интервалу не будет удовлетворена, и ACRS не будет выдаваться в маркере оппортунистически.

Cloud App Security (CAS)

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

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

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

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

Flow	Запрошено ACRS	Примененная политика	Контроль удовлетворен	ACRS добавлено в утверждения
Запросы Ариэль для маркера доступа	"c1"	нет	Да для "c1". Нет для "c2" и "c3"	"c1" (запрошено)
Запросы Ариэль для маркера доступа	"c2"	Политика "Б"	Заблокировано политикой B	нет
Запросы Ариэль для маркера доступа	нет	нет	Да для "c1". Нет для "c2" и "c3"	"c1" (оппортунистически добавлен из политики A)
Jay запрашивает маркер доступа (без MFA)	"c1"	Политика "А"	No	нет
Jay запрашивает маркер доступа (с MFA)	"c1"	Политика "А"	Да	"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" все оппортунистически добавлены

Рекомендации разработчиков по контексту проверки подлинности Условного доступа

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

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

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

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

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

Примеры кода

Контекст проверки подлинности [AR] в ожидаемом поведении условного доступа

Явное удовлетворение контекста проверки подлинности в запросах

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

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

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

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

Cloud App Security (CAS)

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

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

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

Рекомендации разработчиков по контексту проверки подлинности Условного доступа

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

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

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

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

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

Примеры кода

Контекст проверки подлинности [AR] в ожидаемом поведении условного доступа

Явное удовлетворение контекста проверки подлинности в запросах

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

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

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

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

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

Cloud App Security (CAS)

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

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

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