Przewodnik dla deweloperów dotyczący kontekstu uwierzytelniania dostępu warunkowego

Dostęp warunkowy to płaszczyzna sterowania Zero Trust, która umożliwia określanie zasad dostępu do wszystkich aplikacji — starych lub nowych, prywatnych lub publicznych, lokalnych lub wielochmurowych. W kontekście uwierzytelniania dostępu warunkowego można zastosować różne zasady w tych aplikacjach.

Kontekst uwierzytelniania dostępu warunkowego (kontekst uwierzytelniania) umożliwia stosowanie szczegółowych zasad do poufnych danych i akcji zamiast tylko na poziomie aplikacji. Zasady zerowego zaufania można uściślić w celu uzyskania dostępu o najniższych uprawnieniach, jednocześnie minimalizując problemy użytkowników i zapewniając użytkownikom większą produktywność i bezpieczeństwo zasobów. Obecnie są one używane przez aplikacje korzystające z Połączenie OpenId do uwierzytelniania opracowanego przez firmę w celu ochrony poufnych zasobów, takich jak transakcje o wysokiej wartości lub wyświetlanie danych osobowych pracowników.

Aby wyzwolić uwierzytelnianie krokowe z poziomu aplikacji i usług, użyj funkcji kontekstu uwierzytelniania aparatu dostępu warunkowego firmy Microsoft Entra. Deweloperzy mają teraz możliwość popytu na silniejsze uwierzytelnianie, selektywnie, na przykład uwierzytelnianie wieloskładnikowe od użytkowników końcowych z poziomu aplikacji. Ta funkcja ułatwia deweloperom tworzenie bardziej płynnych środowisk użytkownika dla większości części aplikacji, podczas gdy dostęp do bezpieczniejszych operacji i danych pozostaje za silniejszymi mechanizmami kontroli uwierzytelniania.

Opis problemu

Administratorzy IT i organy regulacyjne często zmagają się z równoważeniem, co skłoniło użytkowników do zbyt częstego uwierzytelniania i osiągnięcia odpowiednich zabezpieczeń i przestrzegania zasad dla aplikacji i usług, w których części zawierają poufne dane i operacje. Może to być wybór między silnymi zasadami wpływającymi na produktywność użytkowników, gdy uzyskują dostęp do większości danych i akcji lub zasad, które nie są wystarczająco silne dla poufnych zasobów.

Co więc, jeśli aplikacje były w stanie mieszać się, gdzie mogą działać z stosunkowo mniejszymi zabezpieczeniami i rzadziej monituje większości użytkowników i operacji, a jednak warunkowo zwiększa wymagania bezpieczeństwa, gdy użytkownicy uzyskiwali dostęp do bardziej poufnych części?

Typowe scenariusze

Na przykład użytkownicy mogą logować się do programu SharePoint przy użyciu uwierzytelniania wieloskładnikowego, ale uzyskiwanie dostępu do zbioru witryn w programie SharePoint zawierającego poufne dokumenty może wymagać zgodnego urządzenia i być dostępne tylko z zaufanych zakresów adresów IP.

Wymagania wstępne

Najpierw należy zintegrować aplikację z Platforma tożsamości Microsoft przy użyciu protokołów OpenID Połączenie/ OAuth 2.0 na potrzeby uwierzytelniania i autoryzacji. Zalecamy używanie bibliotek uwierzytelniania Platforma tożsamości Microsoft do integrowania i zabezpieczania aplikacji przy użyciu identyfikatora Entra firmy Microsoft. Platforma tożsamości Microsoft dokumentacji warto zacząć uczyć się integrowania aplikacji z Platforma tożsamości Microsoft. Obsługa funkcji kontekstu uwierzytelniania dostępu warunkowego jest oparta na rozszerzeniach protokołu udostępnianych przez branżowy standard OpenID Połączenie protokołu. Deweloperzy używają wartości referencyjnej kontekstu uwierzytelniania dostępu warunkowego z parametrem Żądanie oświadczeń, aby umożliwić aplikacjom wyzwalanie i spełnianie zasad.

Po drugie dostęp warunkowy wymaga licencjonowania microsoft Entra ID P1. Więcej informacji na temat licencjonowania można znaleźć na stronie cennika firmy Microsoft Entra.

Po trzecie, obecnie jest dostępna tylko dla aplikacji, które loguje użytkowników. Aplikacje, które uwierzytelniają się jako same, nie są obsługiwane. Skorzystaj z przewodnika Przepływy uwierzytelniania i scenariusze aplikacji, aby dowiedzieć się więcej o obsługiwanych typach i przepływach aplikacji uwierzytelniania w Platforma tożsamości Microsoft.

Kroki integracji

Po zintegrowaniu aplikacji przy użyciu obsługiwanych protokołów uwierzytelniania i zarejestrowanych w dzierżawie firmy Microsoft Entra, która ma dostęp warunkowy do użycia, możesz rozpocząć proces integrowania tej funkcji w aplikacjach, które loguje użytkowników.

Uwaga

Szczegółowy przewodnik po tej funkcji jest również dostępny jako zarejestrowana sesja w temacie Korzystanie z kontekstu uwierzytelniania dostępu warunkowego w aplikacji na potrzeby uwierzytelniania krokowego.

Najpierw zadeklaruj i udostępnij konteksty uwierzytelniania w dzierżawie. Aby uzyskać więcej informacji, zobacz Konfigurowanie kontekstów uwierzytelniania.

Wartości C1-C99 są dostępne do użycia jako identyfikatory kontekstu uwierzytelniania w dzierżawie. Przykłady kontekstu uwierzytelniania mogą być następujące:

• C1 — Wymagaj silnego uwierzytelniania
• C2 — wymaganie zgodnych urządzeń
• C3 — wymagaj zaufanych lokalizacji

Utwórz lub zmodyfikuj zasady dostępu warunkowego, aby używać kontekstów uwierzytelniania dostępu warunkowego. Przykładowe zasady mogą być następujące:

• Wszyscy użytkownicy logujący się do tej aplikacji internetowej powinni pomyślnie ukończyć uwierzytelnianie 2FA dla identyfikatora kontekstu uwierzytelniania C1.
• Wszyscy użytkownicy logujący się do tej aplikacji internetowej powinni pomyślnie ukończyć uwierzytelnianie 2FA, a także uzyskać dostęp do aplikacji internetowej z określonego zakresu adresów IP dla identyfikatora kontekstu uwierzytelniania C3.

Uwaga

Wartości kontekstu uwierzytelniania dostępu warunkowego są deklarowane i obsługiwane oddzielnie od aplikacji. Nie zaleca się, aby aplikacje podejmą twardą zależność od identyfikatorów kontekstu uwierzytelniania. Zasady dostępu warunkowego są zwykle tworzone przez administratorów IT, ponieważ lepiej rozumieją zasoby dostępne do zastosowania zasad. Na przykład w przypadku dzierżawy firmy Microsoft Entra administratorzy IT mieliby wiedzę na temat tego, ilu użytkowników dzierżawy jest wyposażonych w korzystanie z uwierzytelniania wieloskładnikowego 2FA, a tym samym może zapewnić, że zasady dostępu warunkowego wymagające uwierzytelniania 2FA są ograniczone do tych wyposażonych użytkowników. Podobnie, jeśli aplikacja jest używana w wielu dzierżawach, identyfikatory kontekstu uwierzytelniania w użyciu mogą być różne i, w niektórych przypadkach, niedostępne w ogóle.

Po drugie: deweloperzy aplikacji planujący korzystanie z kontekstu uwierzytelniania dostępu warunkowego powinni najpierw udostępnić administratorom aplikacji lub administratorom IT środki mapowania potencjalnych poufnych akcji na identyfikatory kontekstu uwierzytelniania. Kroki w przybliżeniu są następujące:

1. Akcje tożsamości w kodzie, które można udostępnić do mapowania na identyfikatory kontekstu uwierzytelniania.
2. Utwórz ekran w portalu administracyjnym aplikacji (lub równoważnej funkcjonalności), którego administratorzy IT mogą używać do mapowania poufnych akcji na dostępny identyfikator kontekstu uwierzytelniania.
3. Zobacz przykładowy kod, użyj kontekstu uwierzytelniania dostępu warunkowego, aby wykonać uwierzytelnianie krokowe, aby zapoznać się z przykładem sposobu jego wykonania.

Te kroki to zmiany, które należy wykonać w bazie kodu. Etapy obejmują zasadniczo

• Wykonaj zapytanie względem programu MS Graph, aby wyświetlić listę wszystkich dostępnych kontekstów uwierzytelniania.
• Zezwalaj administratorom IT na wybieranie operacji poufnych/wysoko uprzywilejowanych i przypisywanie ich do dostępnych kontekstów uwierzytelniania przy użyciu zasad dostępu warunkowego.
• Zapisz te informacje o mapowaniu w magazynie lokalnym/bazie danych.

Po trzecie: Aplikacja, a w tym przykładzie zakładamy, że jest to internetowy interfejs API, a następnie musi ocenić wywołania względem zapisanego mapowania i odpowiednio podnieść wyzwania dotyczące oświadczeń dla aplikacji klienckich. Aby przygotować się do tej akcji, należy wykonać następujące czynności:

1. W operacji kontekstowej uwierzytelniania poufnej i chronionej za pomocą operacji kontekstu uwierzytelniania należy ocenić wartości w oświadczeniu acrs względem mapowań identyfikatora kontekstu uwierzytelniania zapisanych wcześniej i zgłosić żądanie oświadczeń, jak podano w poniższym fragmencie kodu.

2. Na poniższym diagramie przedstawiono interakcję między użytkownikiem, aplikacją kliencją i internetowym interfejsem API.

   

   Poniższy fragment kodu pochodzi z przykładowego kodu, użyj kontekstu uwierzytelniania dostępu warunkowego, aby przeprowadzić uwierzytelnianie krokowe. Pierwsza metoda CheckForRequiredAuthContext() w interfejsie API

   • Sprawdza, czy wywoływana akcja aplikacji wymaga uwierzytelniania krokowego. Robi to, sprawdzając bazę danych pod kątem zapisanego mapowania dla tej metody
   • Jeśli ta akcja rzeczywiście wymaga kontekstu uwierzytelniania z podwyższonym poziomem uprawnień, sprawdza oświadczenie acrs dla istniejącego, zgodnego identyfikatora kontekstu uwierzytelniania.
   • Jeśli nie znaleziono zgodnego identyfikatora kontekstu uwierzytelniania, zgłasza ono wyzwanie dotyczące oświadczeń.

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

   Uwaga

   Format wyzwania roszczeń został opisany w artykule Claims Challenge w Platforma tożsamości Microsoft.

3. W aplikacji klienckiej przechwyć wyzwanie oświadczeń i przekierować użytkownika z powrotem do identyfikatora Entra firmy Microsoft w celu dalszej oceny zasad. Poniższy fragment kodu pochodzi z przykładowego kodu, użyj kontekstu uwierzytelniania dostępu warunkowego, aby przeprowadzić uwierzytelnianie krokowe.

   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;
   }
   

   Obsługa wyjątku w wywołaniu internetowego interfejsu API, jeśli zostanie przedstawione wyzwanie dotyczące oświadczeń, przekierowanie użytkownika z powrotem do identyfikatora Entra firmy Microsoft w celu dalszego przetwarzania.

   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. (Opcjonalnie) Zadeklaruj możliwości klienta. Możliwości klienta pomagają dostawcom zasobów (RP) jak w powyższym internetowym interfejsie API wykryć, czy wywoływana aplikacja kliencka rozumie wyzwanie dotyczące oświadczeń, a następnie odpowiednio dostosować odpowiedź. Ta funkcja może być przydatna, gdy nie wszyscy klienci interfejsów API mogą sprostać wyzwaniom związanym z oświadczeniami, a niektórzy starsi nadal oczekują innej odpowiedzi. Aby uzyskać więcej informacji, zobacz sekcję Możliwości klienta.

Zastrzeżenia i zalecenia

Nie koduj wartości kontekstu uwierzytelniania w aplikacji. Aplikacje powinny odczytywać i stosować kontekst uwierzytelniania przy użyciu wywołań programu MS Graph. Ta praktyka ma kluczowe znaczenie dla aplikacji wielodostępnych. Wartości kontekstu uwierzytelniania różnią się między dzierżawami firmy Microsoft Entra i nie będą dostępne w wersji Microsoft Entra ID Free. Aby uzyskać więcej informacji o tym, jak aplikacja powinna wykonywać zapytania, ustawiać i używać kontekstu uwierzytelniania w kodzie, zobacz przykładowy kod: Używanie kontekstu uwierzytelniania dostępu warunkowego do wykonywania krokowego uwierzytelniania jako sposobu wykonywania zapytań dotyczących aplikacji, ustawiania i używania kontekstu uwierzytelniania w kodzie.

Nie używaj kontekstu uwierzytelniania, w którym sama aplikacja będzie celem zasad dostępu warunkowego. Funkcja działa najlepiej, gdy części aplikacji wymagają od użytkownika spełnienia wyższego paska uwierzytelniania.

Przykłady kodu

• Używanie kontekstu uwierzytelniania dostępu warunkowego do przeprowadzania uwierzytelniania krokowego dla operacji wysokiego poziomu uprawnień w aplikacji internetowej
• Użyj kontekstu uwierzytelniania dostępu warunkowego, aby przeprowadzić uwierzytelnianie krok po kroku dla operacji wysokiego poziomu uprawnień w internetowym interfejsie API
• Używanie kontekstu uwierzytelniania dostępu warunkowego do przeprowadzania uwierzytelniania krokowego dla operacji wysokiego poziomu uprawnień w aplikacji jednostronicowej React i interfejsu API sieci Web Express

Kontekst uwierzytelniania [ACL] w oczekiwanym zachowaniu dostępu warunkowego

Jawne zadowolenie kontekstu uwierzytelniania w żądaniach

Klient może jawnie poprosić o token z kontekstem uwierzytelniania (ACRS) za pośrednictwem oświadczeń w treści żądania. Jeśli zażądano usługi ACRS, dostęp warunkowy umożliwi wystawianie tokenu z żądanym usługą ACRS, jeśli wszystkie wyzwania zostały ukończone.

Oczekiwane zachowanie, gdy kontekst uwierzytelniania nie jest chroniony przez dostęp warunkowy w dzierżawie

Dostęp warunkowy może wystawiać usługę ACRS w oświadczeniach tokenu, gdy wszystkie zasady dostępu warunkowego przypisane do wartości acRS zostały spełnione. Jeśli do wartości acRS nie przypisano żadnych zasad dostępu warunkowego, oświadczenie może być nadal wystawiane, ponieważ zostały spełnione wszystkie wymagania dotyczące zasad.

Tabela podsumowania oczekiwanego zachowania, gdy usługa ACRS jest jawnie żądana

Zażądano usługi ACRS	Zastosowane zasady	Satysfakcjonująca kontrola	Usługa ACRS dodana do oświadczeń
Tak	Nie	Tak	Tak
Tak	Tak	Nie.	Nie.
Tak	Tak	Tak	Tak
Tak	Brak skonfigurowanych zasad z usługą ACRS	Tak	Tak

Niejawne zadowolenie kontekstu uwierzytelniania przez ocenę oportunistyczną

Dostawca zasobów może wyrazić zgodę na opcjonalne oświadczenie "acrs". Dostęp warunkowy próbuje dodać usługę ACRS do oświadczeń tokenu oportunistycznie, aby uniknąć rund w celu uzyskania nowych tokenów do identyfikatora Entra firmy Microsoft. W tej ocenie dostęp warunkowy sprawdza, czy zasady chroniące wyzwania związane z kontekstem uwierzytelniania są już spełnione i dodaje usługę ACRS do oświadczeń tokenu, jeśli tak.

Uwaga

Każdy typ tokenu musi być indywidualnie wybrany (token identyfikatora, token dostępu).

Jeśli dostawca zasobów nie wyrazi zgody na opcjonalne oświadczenie "acrs", jedynym sposobem uzyskania acRS w tokenie będzie jawne żądanie go w żądaniu tokenu. Nie uzyska korzyści z oceny oportunistycznej, dlatego za każdym razem, gdy w oświadczeniach tokenu brakuje wymaganych usług ACRS, dostawca zasobów będzie kwestionować klientowi uzyskanie nowego tokenu zawierającego go w oświadczeniach.

Oczekiwane zachowanie z kontekstem uwierzytelniania i kontrolkami sesji dla niejawnej oceny oportunistycznej acRS

Częstotliwość logowania według interwału

Dostęp warunkowy uwzględnia "częstotliwość logowania według interwału" jako satysfakcjonującą w przypadku oportunistycznej oceny acRS, gdy wszystkie obecne wystąpienia uwierzytelniania czynników uwierzytelniania znajdują się w interwale częstotliwości logowania. W przypadku, gdy pierwszy moment uwierzytelniania czynnika jest nieaktualny lub jeśli drugi współczynnik (MFA) jest obecny, a jego natychmiastowe uwierzytelnianie jest nieaktualne, częstotliwość logowania według interwału nie zostanie spełniona, a acRS nie zostanie wystawiony w tokenie oportunistyczne.

Cloud App Security (CAS)

Dostęp warunkowy będzie uwzględniać kontrolę sesji CAS jako satysfakcjonującą dla oportunistycznej oceny acRS, gdy sesja CAS została ustanowiona podczas tego żądania. Na przykład w przypadku wystąpienia żądania i zastosowania wszystkich zasad dostępu warunkowego i wymuszania sesji CAS, a ponadto istnieją zasady dostępu warunkowego, które również wymagają sesji CAS, ponieważ sesja CAS zostanie wymuszona, która spełni kontrolę sesji CAS na potrzeby oceny oportunistycznej.

Oczekiwane zachowanie, gdy dzierżawa zawiera zasady dostępu warunkowego chroniące kontekst uwierzytelniania

Poniższa tabela zawiera wszystkie przypadki narożne, w których usługa ACRS jest dodawana do oświadczeń tokenu przez ocenę oportunistyczną.

Zasady A: Wymagaj uwierzytelniania wieloskładnikowego od wszystkich użytkowników, z wyłączeniem użytkownika "Ariel", gdy pytasz o acrs "c1". Zasady B: Blokuj wszystkich użytkowników, wykluczając użytkownika "Jay", pytając o acrs "c2" lub "c3".

Flow	Zażądano usługi ACRS	Zastosowane zasady	Satysfakcjonująca kontrola	Usługa ACRS dodana do oświadczeń
Żądania Ariel dotyczące tokenu dostępu	"c1"	Brak	Tak dla "c1". Nie dla "c2" i "c3"	"c1" (żądane)
Żądania Ariel dotyczące tokenu dostępu	"c2"	Zasada B	Zablokowane przez zasady B	Brak
Żądania Ariel dotyczące tokenu dostępu	Brak	Brak	Tak dla "c1". Nie dla "c2" i "c3"	"c1" (oportunistyczne dodane z zasad A)
Jay żąda tokenu dostępu (bez uwierzytelniania wieloskładnikowego)	"c1"	Zasada A	Nie.	Brak
Jay żąda tokenu dostępu (z uwierzytelnianiem wieloskładnikowym)	"c1"	Zasada A	Tak	"c1" (żądane), "c2" (oportunistyczne dodane z zasad B), "c3" (oportunistyczne dodane z zasad B)
Jay żąda tokenu dostępu (bez uwierzytelniania wieloskładnikowego)	"c2"	Brak	Tak dla "c2" i "c3". Nie dla "c1"	"c2" (żądane), "c3" (oportunistyczne dodane z zasad B)
Jay żąda tokenu dostępu (z uwierzytelnianiem wieloskładnikowym)	"c2"	Brak	Tak dla "c1", "c2" i "c3"	"c1" (najlepsze wysiłki od A), "c2" (żądane), "c3" (oportunistyczne dodane z zasad B)
Jay żąda tokenu dostępu (z uwierzytelnianiem wieloskładnikowym)	Brak	Brak	Tak dla "c1", "c2" i "c3"	"c1", "c2", "c3" wszystkie oportunistyczne dodane
Jay żąda tokenu dostępu (bez uwierzytelniania wieloskładnikowego)	Brak	Brak	Tak dla "c2" i "c3". Nie dla "c1"	"c2", "c3" wszystkie oportunistyczne dodane

Następne kroki

• Szczegółowy dostęp warunkowy dla poufnych danych i akcji (blog)
• Zero zaufania z Platforma tożsamości Microsoft
• Kompilowanie aplikacji gotowych do korzystania z platformy Zero Trust za pomocą Platforma tożsamości Microsoft
• Kontekst uwierzytelniania dostępu warunkowego
• authenticationContextClassReference , typ zasobu — MS Graph
• Żądanie oświadczeń, żądania oświadczeń i możliwości klienta w Platforma tożsamości Microsoft
• Używanie kontekstu uwierzytelniania z usługą Microsoft Purview Information Protection i programem SharePoint
• Jak używać interfejsów API z obsługą ciągłego dostępu w aplikacjach