Wskazówki dla deweloperów dotyczące funkcji dostępu warunkowego Azure AD

Ostrzeżenie

Ta zawartość jest przeznaczona dla starszego punktu końcowego Azure AD w wersji 1.0. Użyj Platforma tożsamości Microsoft dla nowych projektów.

Uwaga

Aby uzyskać Platforma tożsamości Microsoft wersję tego artykułu, zobacz Wskazówki dla deweloperów dotyczące dostępu warunkowego Microsoft Entra.

Funkcja dostępu warunkowego w identyfikatorze Microsoft Entra oferuje jeden z kilku sposobów, których można użyć do zabezpieczenia aplikacji i ochrony usługi. 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 Co to jest dostęp warunkowy.

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

Przyjęto znajomość aplikacji z jedną i wieloma dzierżawami oraz typowe wzorce uwierzytelniania .

Jak dostęp warunkowy ma wpływ na aplikację?

Wpływ na typy aplikacji

W większości 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ń" dostępu warunkowego. Może to być tak proste, jak wykonywanie interakcyjnego żądania logowania.

W szczególności następujące scenariusze wymagają kodu do obsługi dostępu warunkowego "wyzwania":

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

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 Typowe zasady dostępu warunkowego.

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, należy zaimplementować obsługę "wyzwania". Poniższe przykłady ilustrują 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 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 wykonać 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 korporacyjny w firmie korzystającej z tej aplikacji stosuje zasady do podrzędnego interfejsu API. Gdy użytkownik końcowy się zaloguje, aplikacja natywna żąda dostępu do warstwy środkowej i wyśle token. Warstwa środkowa wykonuje przepływ w imieniu, aby zażądać dostępu do podrzędnego interfejsu API. W tym momencie oświadczenie "wyzwanie" jest 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ą niektóre zestawy danych, które mogą być stosowane indywidualnie. Ponieważ zasady dostępu warunkowego są przypisane do określonych zestawów danych, Azure AD będzie wymuszać zasady dostępu warunkowego na podstawie danych za wykresem — zamiast grafu.

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

scopes="Bookings.Read.All Mail.Read"

Aplikacja może oczekiwać, że użytkownicy będą spełniać wszystkie zasady ustawione w usłudze Bookings and 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 poziomie 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 wystąpić wyzwanie dotyczące dostępu warunkowego. To wyzwanie jest zakodowane w parametrzeclaims, który pochodzi z odpowiedzi z Azure AD. 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, aby Azure AD. Przekazanie tego stanu powoduje wyświetlenie użytkownikowi końcowemu monitu o wykonanie wszelkich akcji 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ębniania parametru.

Scenariusze

Wymagania wstępne

Microsoft Entra dostęp warunkowy jest funkcją zawartą w identyfikatorze Microsoft Entra P1 lub P2. Więcej informacji na temat wymagań dotyczących licencjonowania można znaleźć w raporcie użycia bez licencji. Deweloperzy mogą dołączyć do usługi Microsoft Developer Network, która obejmuje bezpłatną subskrypcję pakietu Enterprise Mobility Suite, która obejmuje Microsoft Entra identyfikator P1 lub P2.

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 ADAL.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 zastosowano nasze zasady dostępu warunkowego do usługi podrzędnej (internetowy interfejs API 2) i używamy aplikacji natywnej, a nie aplikacji serwera/demona.

Aplikacja wykonująca diagram przepływu w imieniu

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.

Azure AD zwraca odpowiedź HTTP z interesującymi danymi:

Uwaga

W tym przypadku jest to opis błędu uwierzytelniania wieloskładnikowego, ale istnieje szeroki zakres możliwości interaction_required odnoszących się do 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 utworzyć 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.

Aby wypróbować ten scenariusz, zobacz nasz przykładowy kod platformy .NET. Pokazuje on, jak przekazać wyzwanie 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 i 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.

Diagram przepływu aplikacji, który uzyskuje dostęp do wielu usług

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 żąda tokenu dla usługi internetowej B. W tym momencie użytkownik końcowy musi być zgodny z zasadami dostępu warunkowego. Gdy aplikacja próbuje wykonać acquireTokenpróbę , 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>"]}}}

Uzyskiwanie dostępu do wielu usług żądających nowego tokenu

Jeśli aplikacja korzysta z biblioteki ADAL, nie można pobrać tokenu zawsze ponawiać próbę interaktywnie. Po wystąpieniu tego interakcyjnego żądania 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 umożliwić użytkownikowi końcowemu spełnienie zasad.

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

W tym scenariuszu omówimy przypadek, gdy mamy jednostronicową aplikację (SPA), używając ADAL.js wywołania chronionego internetowego interfejsu API dostępu warunkowego. Jest to prosta architektura, ale ma pewne niuanse, które należy wziąć pod uwagę podczas opracowywania wokół dostępu warunkowego.

W ADAL.js istnieje kilka funkcji, które uzyskują tokeny: login(), , acquireToken(...)acquireTokenPopup(…)i acquireTokenRedirect(…).

  • login() uzyskuje token identyfikatora za pośrednictwem interakcyjnego żądania logowania, ale nie uzyskuje tokenów dostępu dla żadnej usługi (w tym internetowego interfejsu API chronionego dostępem warunkowym).
  • acquireToken(…) Następnie można użyć do dyskretnego uzyskania tokenu dostępu, co oznacza, że nie pokazuje interfejsu użytkownika w żadnym przypadku.
  • 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 do wywołania internetowego interfejsu API, podejmuje próbę .acquireToken(…) Jeśli sesja tokenu wygasła lub musimy zachować zgodność z zasadami dostępu warunkowego, funkcja acquireToken kończy się niepowodzeniem, a aplikacja używa acquireTokenPopup() polecenia lub acquireTokenRedirect().

Jednostronicowa aplikacja korzystająca z diagramu przepływu biblioteki ADAL

Zapoznajmy się z przykładem scenariusza dostępu warunkowego. Użytkownik końcowy właśnie wylądował w witrynie i nie ma sesji. Przeprowadzamy wywołanie login() , pobieramy token identyfikatora bez uwierzytelniania wieloskładnikowego. Następnie użytkownik uderza w przycisk, który wymaga od aplikacji żądania danych z internetowego interfejsu API. Aplikacja próbuje wykonać wywołanie, ale kończy się niepowodzeniem acquireToken() , ponieważ użytkownik nie wykonał jeszcze uwierzytelniania wieloskładnikowego i musi być zgodny z zasadami dostępu warunkowego.

Azure AD 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 zostanie wystawiony nowy token dostępu dla żądanego zasobu.

Aby wypróbować ten scenariusz, zobacz nasz przykład kodu JS SPA w imieniu. Ten przykładowy kod używa zasad dostępu warunkowego i internetowego interfejsu API zarejestrowanego wcześniej w spa JS w celu zademonstrowania tego scenariusza. Pokazuje, jak prawidłowo obsługiwać wyzwanie oświadczeń i uzyskać token dostępu, który może być używany dla internetowego interfejsu API. Alternatywnie zapoznaj się z ogólnym przykładem koduAngular.js, aby uzyskać wskazówki dotyczące Angular SPA

Zobacz też