Wskazówki dla programistów dotyczące dostępu warunkowego usługi Microsoft Entra

  • Artykuł

Funkcja dostępu warunkowego w usłudze Microsoft Entra ID oferuje jeden z kilku sposobów, za pomocą których można zabezpieczyć aplikację i chronić usługę. Dostęp warunkowy umożliwia deweloperom i klientom korporacyjnym ochronę usług na wiele sposobów, w tym:

  • Uwierzytelnianie wieloskładnikowe
  • Zezwalanie tylko zarejestrowanym urządzeniom usługi Intune na dostęp do określonych usług
  • Ograniczanie lokalizacji użytkowników i zakresów adresów IP

Aby uzyskać więcej informacji na temat pełnych możliwości dostępu warunkowego, zobacz artykuł Co to jest dostęp warunkowy.

W przypadku deweloperów tworzących aplikacje dla identyfikatora Entra firmy Microsoft w tym artykule pokazano, jak można używać dostępu warunkowego, a także dowiesz się więcej na temat wpływu uzyskiwania dostępu do zasobów, które nie mają kontroli nad tym, które mogą mieć zastosowane zasady dostępu warunkowego. W tym artykule opisano również konsekwencje dostępu warunkowego w przepływie, aplikacjach internetowych, uzyskiwaniu dostępu do programu Microsoft Graph i wywoływaniu interfejsów API.

Przyjmuje się, że przyjmuje się wiedzę na temat aplikacji pojedynczych i wielodostępnych oraz typowych wzorców uwierzytelniania.

Uwaga

Korzystanie z tej funkcji wymaga licencji Microsoft Entra ID P1. Aby znaleźć licencję odpowiednią do wymagań, zobacz porównanie ogólnodostępnych funkcji w wersji bezpłatnej, podstawowej i premium. Klienci z licencjami platformy Microsoft 365 Business mają również dostęp do funkcji dostępu warunkowego.

Jak dostęp warunkowy wpływa na aplikację?

Typy aplikacji, których dotyczy ten wpływ

W większości typowych przypadków dostęp warunkowy nie zmienia zachowania aplikacji ani nie wymaga żadnych zmian od dewelopera. Tylko w niektórych przypadkach, gdy aplikacja pośrednio lub dyskretnie żąda tokenu dla usługi, aplikacja wymaga zmian kodu w celu obsługi wyzwań związanych z dostępem warunkowym. Może to być tak proste, jak wykonywanie interakcyjnego żądania logowania.

W szczególności następujące scenariusze wymagają kodu do obsługi wyzwań związanych z dostępem warunkowym:

  • Aplikacje wykonujące przepływ w imieniu
  • Aplikacje, które uzyskują dostęp do wielu usług/zasobów
  • Aplikacje jednostronicowe korzystające z MSAL.js
  • Usługa Web Apps wywołująca zasób

Zasady dostępu warunkowego można zastosować do aplikacji, ale można również zastosować do internetowego interfejsu API, do których uzyskuje się dostęp do aplikacji. Aby dowiedzieć się więcej na temat konfigurowania zasad dostępu warunkowego, zobacz Szybki start: wymaganie uwierzytelniania wieloskładnikowego dla określonych aplikacji przy użyciu dostępu warunkowego firmy Microsoft Entra.

W zależności od scenariusza klient przedsiębiorstwa może w dowolnym momencie zastosować i usunąć zasady dostępu warunkowego. Aby aplikacja nadal działała po zastosowaniu nowych zasad, zaimplementuj obsługę wyzwań. W poniższych przykładach pokazano obsługę wyzwań.

Przykłady dostępu warunkowego

Niektóre scenariusze wymagają zmian kodu w celu obsługi dostępu warunkowego, podczas gdy inne działają tak, jak to jest. Poniżej przedstawiono kilka scenariuszy korzystających z dostępu warunkowego do uwierzytelniania wieloskładnikowego, które zapewnia pewien wgląd w różnicę.

  • Tworzysz aplikację dla systemu iOS z jedną dzierżawą i stosujesz zasady dostępu warunkowego. Aplikacja loguje się do użytkownika i nie żąda dostępu do interfejsu API. Gdy użytkownik się zaloguje, zasady są wywoływane automatycznie, a użytkownik musi przeprowadzić uwierzytelnianie wieloskładnikowe (MFA).
  • Tworzysz aplikację natywną, która używa usługi warstwy środkowej do uzyskiwania dostępu do podrzędnego interfejsu API. Klient przedsiębiorstwa w firmie korzystającej z tej aplikacji stosuje zasady do interfejsu API podrzędnego. Gdy użytkownik końcowy się zaloguje, aplikacja natywna żąda dostępu do warstwy środkowej i wysyła token. Warstwa środkowa wykonuje przepływ w imieniu, aby zażądać dostępu do podrzędnego interfejsu API. W tym momencie oświadczenia "wyzwanie" są prezentowane w warstwie środkowej. Warstwa środkowa wysyła wyzwanie z powrotem do aplikacji natywnej, która musi być zgodna z zasadami dostępu warunkowego.

Microsoft Graph

Program Microsoft Graph ma specjalne uwagi dotyczące tworzenia aplikacji w środowiskach dostępu warunkowego. Ogólnie rzecz biorąc, mechanika dostępu warunkowego zachowuje się tak samo, ale zasady widoczne dla użytkowników będą oparte na danych bazowych, których aplikacja żąda z grafu.

W szczególności wszystkie zakresy programu Microsoft Graph reprezentują zestaw danych, który może mieć zastosowanie indywidualnie. Ponieważ zasady dostępu warunkowego są przypisane do określonych zestawów danych, identyfikator Firmy Microsoft Entra wymusza zasady dostępu warunkowego na podstawie danych za pomocą programu Graph — a nie samego programu Graph.

Jeśli na przykład aplikacja żąda następujących zakresów programu Microsoft Graph,

scopes="ChannelMessages.Read.All Mail.Read"

Aplikacja może oczekiwać, że użytkownicy spełnią wszystkie zasady ustawione w usłudze Teams i programie Exchange. Niektóre zakresy mogą być mapowe na wiele zestawów danych, jeśli udziela dostępu.

Zgodność z zasadami dostępu warunkowego

W przypadku kilku różnych topologii aplikacji zasady dostępu warunkowego są oceniane po ustanowieniu sesji. Ponieważ zasady dostępu warunkowego działają na stopień szczegółowości aplikacji i usług, punkt, w którym jest wywoływany, zależy w dużym stopniu od scenariusza, który próbujesz osiągnąć.

Gdy aplikacja próbuje uzyskać dostęp do usługi przy użyciu zasad dostępu warunkowego, może napotkać wyzwanie dostępu warunkowego. To wyzwanie jest zakodowane w parametrze claims , który pochodzi w odpowiedzi z identyfikatora Entra firmy Microsoft. Oto przykład tego parametru wyzwania:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Deweloperzy mogą podjąć to wyzwanie i dołączyć je do nowego żądania do identyfikatora Entra firmy Microsoft. Przekazanie tego stanu powoduje wyświetlenie użytkownikowi końcowemu monitu o wykonanie wszelkich działań niezbędnych do zachowania zgodności z zasadami dostępu warunkowego. W poniższych scenariuszach objaśniono szczegóły błędu i sposób wyodrębnienia parametru.

Scenariusze

Wymagania wstępne

Microsoft Entra Conditional Access to funkcja zawarta w microsoft Entra ID P1 lub P2. Klienci z licencjami platformy Microsoft 365 Business mają również dostęp do funkcji dostępu warunkowego.

Zagadnienia dotyczące konkretnych scenariuszy

Następujące informacje dotyczą tylko tych scenariuszy dostępu warunkowego:

  • Aplikacje wykonujące przepływ w imieniu
  • Aplikacje, które uzyskują dostęp do wielu usług/zasobów
  • Aplikacje jednostronicowe korzystające z MSAL.js

W poniższych sekcjach omówiono typowe scenariusze, które są bardziej złożone. Podstawowa zasada działania to zasady dostępu warunkowego są oceniane w momencie żądania tokenu dla usługi, która ma zastosowane zasady dostępu warunkowego.

Scenariusz: Aplikacja wykonująca przepływ On-Behalf-Of

W tym scenariuszu omówimy przypadek, w którym aplikacja natywna wywołuje usługę internetową/interfejs API. Z kolei ta usługa wykonuje przepływ "w imieniu" w celu wywołania usługi podrzędnej. W naszym przypadku zastosowaliśmy nasze zasady dostępu warunkowego do usługi podrzędnej (internetowy interfejs API 2) i używamy aplikacji natywnej, a nie aplikacji serwera/demona.

App performing the on-behalf-of flow diagram

Początkowe żądanie tokenu dla internetowego interfejsu API 1 nie monituje użytkownika końcowego o uwierzytelnianie wieloskładnikowe, ponieważ internetowy interfejs API 1 nie zawsze może trafić do podrzędnego interfejsu API. Gdy internetowy interfejs API 1 próbuje zażądać tokenu w imieniu użytkownika dla internetowego interfejsu API 2, żądanie kończy się niepowodzeniem, ponieważ użytkownik nie zalogował się przy użyciu uwierzytelniania wieloskładnikowego.

Identyfikator Entra firmy Microsoft zwraca odpowiedź HTTP z interesującymi danymi:

Uwaga

W tym przypadku jest to opis błędu uwierzytelniania wieloskładnikowego, ale istnieje wiele interaction_required możliwych kwestii dotyczących dostępu warunkowego.

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

W internetowym interfejsie API 1 przechwycimy błąd error=interaction_requiredi wyślemy claims wyzwanie do aplikacji klasycznej. W tym momencie aplikacja klasyczna może wykonać nowe acquireToken() wywołanie i dołączyć claimswyzwanie jako dodatkowy parametr ciągu zapytania. To nowe żądanie wymaga od użytkownika przeprowadzenia uwierzytelniania wieloskładnikowego, a następnie wysłania tego nowego tokenu z powrotem do internetowego interfejsu API 1 i ukończenia przepływu w imieniu użytkownika.

Aby wypróbować ten scenariusz, zobacz nasz przykładowy kod platformy .NET. Pokazuje on, jak przekazać żądanie oświadczeń z powrotem z internetowego interfejsu API 1 do aplikacji natywnej i utworzyć nowe żądanie wewnątrz aplikacji klienckiej.

Scenariusz: Uzyskiwanie dostępu do wielu usług przez aplikację

W tym scenariuszu omówimy przypadek, w którym aplikacja internetowa uzyskuje dostęp do dwóch usług z przypisanymi zasadami dostępu warunkowego. W zależności od logiki aplikacji może istnieć ścieżka, w której aplikacja nie wymaga dostępu do obu usług internetowych. W tym scenariuszu kolejność żądania tokenu odgrywa ważną rolę w środowisku użytkownika końcowego.

Załóżmy, że mamy usługę internetową A i B oraz usługę internetową B, w których zastosowano nasze zasady dostępu warunkowego. Chociaż początkowe żądanie uwierzytelniania interakcyjnego wymaga zgody dla obu usług, zasady dostępu warunkowego nie są wymagane we wszystkich przypadkach. Jeśli aplikacja żąda tokenu dla usługi internetowej B, zasady są wywoływane, a kolejne żądania dla usługi internetowej A również kończą się powodzeniem w następujący sposób.

App accessing multiple-services flow diagram

Alternatywnie, jeśli aplikacja początkowo żąda tokenu dla usługi internetowej A, użytkownik końcowy nie wywołuje zasad dostępu warunkowego. Dzięki temu deweloper aplikacji może kontrolować środowisko użytkownika końcowego, a nie wymuszać wywołania zasad dostępu warunkowego we wszystkich przypadkach. Trudny przypadek polega na tym, że aplikacja później żąda tokenu dla usługi internetowej B. W tym momencie użytkownik końcowy musi być zgodny z zasadami dostępu warunkowego. Gdy aplikacja podejmie próbę acquireToken, może wygenerować następujący błąd (pokazany na poniższym diagramie):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App accessing multiple services requesting a new token

Jeśli aplikacja korzysta z biblioteki MSAL, nie można pobrać tokenu zawsze ponawiana interaktywnie. Gdy wystąpi to interakcyjne żądanie, użytkownik końcowy ma możliwość zachowania zgodności z dostępem warunkowym. Jest to prawda, chyba że żądanie jest żądaniem AcquireTokenSilentAsync lub PromptBehavior.Never w takim przypadku aplikacja musi wykonać interakcyjne AcquireToken żądanie, aby dać użytkownikowi końcowemu możliwość zachowania zgodności z zasadami.

Scenariusz: aplikacja jednostronicowa (SPA) korzystająca z MSAL.js

W tym scenariuszu omówimy ten przypadek, gdy mamy jednostronicową aplikację (SPA) wywołującą chroniony internetowy interfejs API dostępu warunkowego przy użyciu MSAL.js. Jest to prosta architektura, ale ma pewne niuanse, które należy wziąć pod uwagę podczas opracowywania wokół dostępu warunkowego.

W MSAL.js istnieje kilka funkcji, które uzyskują tokeny: acquireTokenSilent(), acquireTokenPopup()i acquireTokenRedirect().

  • acquireTokenSilent() można użyć do dyskretnego uzyskania tokenu dostępu, co oznacza, że nie pokazuje interfejsu użytkownika w żadnych okolicznościach.
  • acquireTokenPopup() i acquireTokenRedirect() są używane do interaktywnego żądania tokenu dla zasobu, co oznacza, że zawsze wyświetlają interfejs użytkownika logowania.

Gdy aplikacja potrzebuje tokenu dostępu w celu wywołania internetowego interfejsu API, podejmuje próbę .acquireTokenSilent() Jeśli token wygasł lub musimy zachować zgodność z zasadami dostępu warunkowego, funkcja acquireToken kończy się niepowodzeniem, a aplikacja używa acquireTokenPopup() metody lub acquireTokenRedirect().

Single-page app using MSAL flow diagram

Przyjrzyjmy się przykładowi scenariusza dostępu warunkowego. Użytkownik końcowy właśnie wylądował w witrynie i nie ma sesji. Wykonujemy wywołanie loginPopup() , uzyskujemy token identyfikatora bez uwierzytelniania wieloskładnikowego. Następnie użytkownik osiągnie przycisk, który wymaga, aby aplikacja zażądała danych z internetowego interfejsu API. Aplikacja próbuje wykonać wywołanie, ale kończy się niepowodzeniem acquireTokenSilent() , ponieważ użytkownik nie wykonał jeszcze uwierzytelniania wieloskładnikowego i musi być zgodny z zasadami dostępu warunkowego.

Identyfikator Entra firmy Microsoft wysyła z powrotem następującą odpowiedź HTTP:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

Nasza aplikacja musi przechwycić element error=interaction_required. Następnie aplikacja może używać tego acquireTokenPopup() samego zasobu lub acquireTokenRedirect() w tym samym zasobie. Użytkownik jest zmuszony do przeprowadzenia uwierzytelniania wieloskładnikowego. Po zakończeniu uwierzytelniania wieloskładnikowego aplikacja otrzymuje nowy token dostępu dla żądanego zasobu.

Aby wypróbować ten scenariusz, zobacz nasz przykładowy kod react SPA wywołujący Node.js internetowy interfejs API przy użyciu kodu przepływu w imieniu. Ten przykładowy kod używa zasad dostępu warunkowego i internetowego interfejsu API zarejestrowanego wcześniej w aplikacji React SPA w celu zademonstrowania tego scenariusza. Pokazuje on, jak prawidłowo obsługiwać wyzwanie dotyczące oświadczeń i uzyskać token dostępu, który może być używany dla internetowego interfejsu API.

Zobacz też