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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

   Примечание.

   Формат вызова утверждений описан в статье "Вызов утверждений" в платформа удостоверений Майкрософт.

3. В клиентском приложении перехватите вызов утверждений и перенаправьте пользователя обратно в идентификатор 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");
   

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

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

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

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

Примеры кода

• Использование контекста проверки подлинности Условного доступа для выполнения проверки подлинности повышенного уровня для высокопривилегированных операций в веб-приложении
• Использование контекста проверки подлинности Условного доступа для выполнения проверки подлинности повышенного уровня для высокопривилегированных операций в веб-API
• Использование контекста проверки подлинности условного доступа для выполнения поэтапной проверки подлинности для операций с высоким уровнем привилегий в одностраничном приложении React и веб-API Express

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

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

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

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

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

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

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

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

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

• Точный условный доступ для конфиденциальных данных и действий (Блог)
• Нулевое доверие с платформа удостоверений Майкрософт
• Создание готовых приложений нулевого доверия с помощью платформа удостоверений Майкрософт
• Контекст проверки подлинности Условного доступа
• Тип ресурса authenticationContextClassReference. MS Graph
• Требования утверждений, запросы на утверждение и возможности клиента на Платформе удостоверений Майкрософт
• Использование контекста проверки подлинности с помощью Microsoft Purview Information Protection и SharePoint
• Как использовать API с поддержкой Непрерывной оценки доступа в приложениях