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

Область применения: арендаторы рабочей силы внешние арендаторы (узнать больше)

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

Помимо применения политик исключительно на уровне приложения, контекст проверки подлинности Условного доступа (контекст аутентификации) позволяет применять детализированные политики к конфиденциальным данным и действиям. Вы можете уточнить политики "Никому не доверяй" для получения наименее привилегированного доступа при минимальных трениях между пользователями, повышении производительности пользователей и большей безопасности ваших ресурсов. Сегодня оно используется приложениями с помощью 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.
• Все пользователи, входящие в это веб-приложение, должны успешно пройти 2FA, а также иметь доступ к приложению из заданного диапазона 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. (Необязательно) Объявите возможности клиента. Клиентские возможности помогают поставщикам ресурсов (RP), таким как наш веб-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, когда все эти факторы проверки подлинности находятся в пределах интервала частоты входа. В случае, если один из факторов аутентификации устарел, частота ввода по интервалу не будет удовлетворена, и ACRS не будет выдан в токене согласно возможности.

Cloud App Security (CAS)

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

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

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

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

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

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