Instrukcje: Logowanie się dowolnego użytkownika usługi Azure Active Directory za pomocą wzorca aplikacji wielodostępnych

Jeśli oferujesz aplikację oprogramowanie jako usługa (SaaS) w wielu organizacjach, możesz skonfigurować aplikację tak, aby akceptowała logowania z dowolnej dzierżawy usługi Azure Active Directory (Azure AD). Ta konfiguracja jest nazywana tworzeniem wielu dzierżawców aplikacji. Użytkownicy w dowolnej dzierżawie usługi Azure AD będą mogli zalogować się do aplikacji po dojściu do korzystania z konta w aplikacji.

Jeśli masz istniejącą aplikację, która ma własny system kont lub obsługuje inne rodzaje logowań z innych dostawców chmury, Dodawanie logowania za pomocą usługi Azure AD z dowolnego dzierżawy jest proste. Po prostu zarejestruj aplikację, Dodaj kod logowania za pośrednictwem OAuth2, OpenID Connect Connect lub SAML i umieść przycisk "Zaloguj się przy użyciu konta Microsoft" w aplikacji.

Uwaga

W tym artykule założono, że wiesz już, jak utworzyć aplikację z jedną dzierżawą dla usługi Azure AD. Jeśli nie, Zacznij od jednego z szybkich samouczków na stronie głównej przewodnika dla deweloperów.

Istnieją cztery kroki umożliwiające przekonwertowanie aplikacji do aplikacji wielodostępnej usługi Azure AD:

  1. Aktualizowanie rejestracji aplikacji w ramach wielu dzierżawców
  2. Aktualizowanie kodu w celu wysyłania żądań do punktu końcowego/typowe
  3. Zaktualizuj swój kod, aby obsługiwał wiele wartości wystawcy
  4. Zrozumienie zgody użytkownika i administratora oraz wprowadzenie odpowiednich zmian w kodzie

Przyjrzyjmy się szczegółowym krokom. Możesz również przejść bezpośrednio do przykładowej kompilacji wielodostępnej aplikacji sieci Web SaaS, która wywołuje Microsoft Graph przy użyciu usługi Azure AD i OpenID Connect Connect.

Aktualizowanie rejestracji w ramach wielu dzierżawców

Domyślnie Rejestracja aplikacji sieci Web/interfejsu API w usłudze Azure AD jest pojedynczą dzierżawą. Możesz dokonać rejestracji wielu dzierżawców, wyszukując ustawienia obsługiwane typy kont w okienku uwierzytelnianie rejestracji aplikacji w Azure Portal i ustawiając je na konta w dowolnym katalogu organizacyjnym.

Aby można było nawiązać aplikację z wieloma dzierżawcami, usługa Azure AD wymaga, aby identyfikator URI aplikacji był globalnie unikatowy. Identyfikator URI identyfikatora aplikacji jest jednym ze sposobów, w jaki aplikacja jest identyfikowana w komunikatach protokołu. W przypadku aplikacji jednodostępnej wystarczy, aby identyfikator URI identyfikatora aplikacji był unikatowy w obrębie tej dzierżawy. W przypadku aplikacji wielodostępnej ten identyfikator musi być globalnie unikatowy, dzięki czemu usługa Azure AD będzie mogła znaleźć aplikację we wszystkich dzierżawach. Globalna unikatowość jest wymuszana poprzez wymaganie, aby identyfikator URI identyfikatora aplikacji miał nazwę hosta, która jest zgodna ze zweryfikowaną domeną dzierżawy usługi Azure AD.

Domyślnie aplikacje utworzone za pośrednictwem Azure Portal mają globalnie unikatowy identyfikator URI aplikacji ustawiony podczas tworzenia aplikacji, ale można zmienić tę wartość. Na przykład, jeśli nazwa dzierżawy została contoso.onmicrosoft.com, prawidłowy identyfikator URI aplikacji będzie mieć wartość https://contoso.onmicrosoft.com/myapp . Jeśli Twoja dzierżawa ma zweryfikowaną domenę contoso.com , prawidłowy identyfikator URI aplikacji również będzie mieć wartość https://contoso.com/myapp . Jeśli identyfikator URI identyfikatora aplikacji nie jest zgodny z tym wzorcem, ustawienie aplikacji jako aplikacji wielodostępnej zakończy się niepowodzeniem.

Aktualizowanie kodu w celu wysyłania żądań do/typowe

W przypadku aplikacji z jedną dzierżawą żądania logowania są wysyłane do punktu końcowego logowania dzierżawcy. Na przykład dla contoso.onmicrosoft.com punkt końcowy będzie: https://login.microsoftonline.com/contoso.onmicrosoft.com . Żądania wysyłane do punktu końcowego dzierżawy mogą logować użytkowników (lub Gości) w tej dzierżawie do aplikacji w tej dzierżawie.

W przypadku aplikacji z wieloma dzierżawcami aplikacja nie wie, z której dzierżawą pochodzi użytkownik, i nie może wysyłać żądań do punktu końcowego dzierżawy. Zamiast tego żądania są wysyłane do punktu końcowego, który ma wszystkie dzierżawy usługi Azure AD: https://login.microsoftonline.com/common

Gdy platforma tożsamości firmy Microsoft odbiera żądanie w punkcie końcowym/typowe, podpisuje użytkownika w i, w związku z tym, wykrywa dzierżawę, z której pochodzi użytkownik. Punkt końcowy/typowe współpracuje ze wszystkimi protokołami uwierzytelniania obsługiwanymi przez usługę Azure AD: OpenID Connect Connect, OAuth 2,0, SAML 2,0 i WS-Federation.

Odpowiedź na logowanie do aplikacji zawiera token reprezentujący użytkownika. Wartość wystawcy w tokenie instruuje aplikację, z której pochodzi użytkownik. Po powrocie odpowiedzi z punktu końcowego/typowe wartość wystawcy w tokenie odpowiada dzierżawcy użytkownika.

Ważne

Punkt końcowy/typowe nie jest dzierżawcą i nie jest wystawcą. jest tylko multiplekserem. W przypadku korzystania z/typowe logika w aplikacji do weryfikacji tokenów musi zostać zaktualizowana w celu uwzględnienia tego konta.

Zaktualizuj swój kod, aby obsługiwał wiele wartości wystawcy

Aplikacje sieci Web i interfejsy API sieci Web odbierają i weryfikują tokeny z platformy tożsamości firmy Microsoft.

Uwaga

Natywne aplikacje klienckie żądają tokenów od platformy tożsamości firmy Microsoft, a następnie wysyłają je do interfejsów API, gdzie są weryfikowane. Natywne aplikacje nie weryfikują tokenów dostępu i muszą traktować je jako nieprzezroczyste.

Przyjrzyjmy się, jak aplikacja sprawdza poprawność tokenów odbieranych z platformy tożsamości firmy Microsoft. Aplikacja o pojedynczej dzierżawie zazwyczaj przyjmuje wartość punktu końcowego, taką jak:

https://login.microsoftonline.com/contoso.onmicrosoft.com

... i używa go do konstruowania adresu URL metadanych (w tym przypadku OpenID Connect Connect), takich jak:

https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

Aby pobrać dwie krytyczne informacje, które są używane do weryfikacji tokenów: klucze podpisywania i wartość wystawcy dzierżawcy.

Każda dzierżawa usługi Azure AD ma unikatową wartość wystawcy w postaci:

https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/

... gdzie GUID wartością jest wersja z bezpiecznym zmianami identyfikatora dzierżawy dzierżawy. W przypadku wybrania poprzedniego linku metadanych dla programu contoso.onmicrosoft.com można zobaczyć tę wartość wystawcy w dokumencie.

Gdy aplikacja z jedną dzierżawą weryfikuje token, sprawdza podpis tokenu względem kluczy podpisywania z dokumentu metadanych. Ten test pozwala na upewnienie się, że wartość wystawcy w tokenie jest zgodna z tą, która została znaleziona w dokumencie metadanych.

Ponieważ punkt końcowy/typowe nie odpowiada dzierżawcy i nie jest wystawcą, podczas badania wartości wystawcy w metadanych dla/typowe ma adres URL z szablonem, a nie rzeczywistą wartość:

https://sts.windows.net/{tenantid}/

W związku z tym aplikacja wielodostępna nie może zweryfikować tokenów tylko przez dopasowanie wartości wystawcy w metadanych przy użyciu issuer wartości w tokenie. Aplikacja wielodostępna wymaga logiki, która decyduje o tym, które wartości wystawcy są prawidłowe i które nie są oparte na części identyfikatora dzierżawy wartości wystawcy.

Jeśli na przykład aplikacja wielodostępna zezwala tylko na logowanie się z określonych dzierżawców, którzy zarejestrowali się w celu korzystania z usługi, musi sprawdzić wartość wystawcy lub tid wartość żądania w tokenie, aby upewnić się, że dzierżawa znajduje się na liście subskrybentów. Jeśli aplikacja wielodostępna zajmuje się tylko osobom i nie podejmuje decyzji o dostępie na podstawie dzierżawców, może całkowicie zignorować wartość wystawcy.

W przykładach z wieloma dzierżawcamiweryfikacja wystawcy jest wyłączona, aby umożliwić zalogowanie się w dzierżawie usługi Azure AD.

Aby użytkownik mógł zalogować się do aplikacji w usłudze Azure AD, aplikacja musi być reprezentowana w dzierżawie użytkownika. Dzięki temu organizacja może wykonywać takie czynności, jak stosowanie unikatowych zasad, gdy użytkownicy z ich dzierżawy logują się do aplikacji. Ta rejestracja jest łatwiejsza dla aplikacji z jedną dzierżawą; jest to taka, która występuje po zarejestrowaniu aplikacji w Azure Portal.

W przypadku aplikacji z wieloma dzierżawami początkowa Rejestracja aplikacji jest używana w dzierżawie usługi Azure AD używanej przez dewelopera. Gdy użytkownik z innej dzierżawy loguje się do aplikacji po raz pierwszy, usługa Azure AD poprosi o zgodę na uprawnienia wymagane przez aplikację. Jeśli użytkownik wyrazi zgodę, reprezentacja aplikacji zwanej jednostką usługi jest tworzona w dzierżawie użytkownika, a logowanie może być kontynuowane. W katalogu zostanie również utworzona delegacja, która rejestruje zgodę użytkownika na aplikację. Aby uzyskać szczegółowe informacje na temat aplikacji i obiektów serviceprincipal aplikacji oraz jak są one ze sobą powiązane, zobacz obiekty aplikacji i obiekty główne usługi.

Przedstawia zgodę na aplikację jednowarstwową

Do tej zgody mają wpływ uprawnienia wymagane przez aplikację. Platforma tożsamości firmy Microsoft obsługuje dwa rodzaje uprawnień, tylko aplikacje i delegowane.

  • Delegowane uprawnienie przyznaje aplikacji możliwość działania jako użytkownik zalogowany dla podzbioru rzeczy, które może wykonywać użytkownik. Na przykład można udzielić aplikacji uprawnienia delegowane do odczytu kalendarza zalogowanego użytkownika.
  • Uprawnienie tylko do aplikacji jest udzielane bezpośrednio do tożsamości aplikacji. Na przykład można udzielić aplikacji uprawnienia tylko do odczytu listy użytkowników w dzierżawie, niezależnie od tego, kto jest zalogowany do aplikacji.

Niektóre uprawnienia mogą być wysyłane przez zwykłego użytkownika, a inne wymagają zgody administratora dzierżawy.

Aby dowiedzieć się więcej o zgodzie użytkowników i administratorów, zobacz Konfigurowanie przepływu pracy zgody administratora.

Uprawnienia dotyczące tylko aplikacji zawsze wymagają zgody administratora dzierżawy. Jeśli aplikacja żąda uprawnień tylko do aplikacji, a użytkownik próbuje zalogować się do aplikacji, zostanie wyświetlony komunikat o błędzie informujący o tym, że użytkownik nie jest w stanie wyrazić zgody.

Niektóre uprawnienia delegowane wymagają również zgody administratora dzierżawy. Na przykład możliwość zapisu zwrotnego w usłudze Azure AD jako zalogowany użytkownik wymaga zgody administratora dzierżawy. Podobnie jak uprawnienia tylko do aplikacji, jeśli zwykły użytkownik próbuje zalogować się do aplikacji, która żąda delegowanego uprawnienia, które wymaga zgody administratora, aplikacja otrzymuje błąd. Niezależnie od tego, czy uprawnienie wymaga zgody administratora, jest określane przez dewelopera, który opublikował zasób, i można je znaleźć w dokumentacji dotyczącej zasobu. Dokumentacja dotycząca uprawnień dla interfejsu API Microsoft Graph wskazuje, które uprawnienia wymagają zgody administratora.

Jeśli aplikacja korzysta z uprawnień, które wymagają zgody administratora, powinien mieć gest, taki jak przycisk lub link, w którym administrator może zainicjować akcję. Żądanie wysyłane przez aplikację dla tej akcji to zwykłe żądanie autoryzacji OAuth2/OpenID Connect połączenia, które zawiera również prompt=admin_consent parametr ciągu zapytania. Gdy administrator wyraził zgodę, a jednostka usługi zostanie utworzona w dzierżawie klienta, kolejne żądania logowania nie potrzebują prompt=admin_consent parametru. Ze względu na to, że administrator zdecydował się, że żądane uprawnienia są akceptowalne, żaden inny użytkownik w dzierżawie nie zostanie poproszony o zgodę od tego momentu.

Administrator dzierżawy może wyłączyć możliwość wyrażania zgody na aplikacje przez zwykłych użytkowników. Jeśli ta funkcja jest wyłączona, zgoda administratora jest zawsze wymagana do używania aplikacji w dzierżawie. Jeśli chcesz przetestować aplikację z wyłączoną zgodą użytkownika końcowego, możesz znaleźć przełącznik konfiguracji w Azure Portal w sekcji Ustawienia użytkownika w obszarze aplikacje dla przedsiębiorstw.

Ten prompt=admin_consent parametr może być również używany przez aplikacje żądające uprawnień, które nie wymagają zgody administratora. Przykładem sytuacji, w której będzie on używany, jest to, że aplikacja wymaga środowiska, w którym Administrator dzierżawy jest "jednokrotne", a inni użytkownicy nie otrzymują monitu o zgodę od tego momentu.

Jeśli aplikacja wymaga zgody administratora, a administrator loguje się bez prompt=admin_consent wysyłanego parametru, gdy administrator pomyślnie wyraził zgodę na aplikację, zostanie ona zastosowana tylko do konta użytkownika. Regularne użytkownicy nadal nie będą mogli zalogować się ani wyrazić zgody na aplikację. Ta funkcja jest przydatna, jeśli chcesz dać administratorowi dzierżawy możliwość eksplorowania aplikacji przed zezwoleniem innym użytkownikom na dostęp.

Aplikacja może mieć wiele warstw, z których każda jest reprezentowana przez własną rejestrację w usłudze Azure AD. Na przykład aplikacja natywna, która wywołuje interfejs API sieci Web, lub aplikację sieci Web, która wywołuje interfejs API sieci Web. W obu przypadkach klient (aplikacja natywna lub aplikacja sieci Web) żąda uprawnień do wywoływania zasobu (internetowy interfejs API). Aby klient mógł zostać pomyślnie przesłany do dzierżawy klienta, wszystkie zasoby, do których żąda uprawnień, muszą już istnieć w dzierżawie klienta. Jeśli ten warunek nie zostanie spełniony, usługa Azure AD zwróci błąd, aby najpierw dodać zasób.

Wiele warstw w jednej dzierżawie

Może to być problem, jeśli aplikacja logiczna składa się z co najmniej dwóch rejestracji aplikacji, na przykład oddzielnego klienta i zasobu. Jak należy najpierw pobrać zasób do dzierżawy klienta? Usługa Azure AD omawia ten przypadek, umożliwiając klientowi i zalogowanie się w jednym kroku. Użytkownik widzi łączną sumę uprawnień wymaganych przez klienta i zasób na stronie wyrażania zgody. Aby włączyć to zachowanie, Rejestracja aplikacji zasobu musi zawierać identyfikator aplikacji klienta jako element knownClientApplications w manifeście aplikacji. Na przykład:

"knownClientApplications": ["94da0930-763f-45c7-8d26-04d5938baab2"]

Jest to zademonstrowane w ramach wielowarstwowego, natywnego wywołania interfejsu API sieci Web w sekcji powiązanej zawartości na końcu tego artykułu. Poniższy diagram zawiera omówienie wyrażania zgody dla aplikacji wielowarstwowej zarejestrowanej w ramach jednej dzierżawy.

Przedstawia zgodę na znaną aplikację kliencką wielowarstwową

Wiele warstw w wielu dzierżawcach

Podobny przypadek ma miejsce, jeśli różne warstwy aplikacji są zarejestrowane w różnych dzierżawach. Rozważmy na przykład przypadek tworzenia natywnej aplikacji klienckiej, która wywołuje interfejs API usługi Exchange Online. Aby opracować aplikację natywną, a później w celu uruchomienia aplikacji natywnej w dzierżawie klienta musi być obecna nazwa główna usługi Exchange Online. W takim przypadku deweloper i klient muszą zakupić usługę Exchange Online w celu utworzenia jednostki usługi w swoich dzierżawach.

Jeśli jest to interfejs API zbudowany przez organizację inną niż Microsoft, deweloper interfejsu API musi zapewnić klientom zgodę na stosowanie aplikacji do dzierżawców klientów. Zalecany projekt jest przeznaczony dla deweloperów innych firm do kompilowania interfejsu API w taki sposób, że może on również działać jako klient sieci Web w celu zaimplementowania rejestracji. W tym celu:

  1. Postępuj zgodnie z wcześniejszymi sekcjami, aby upewnić się, że interfejs API implementuje wymagania dotyczące rejestracji/kodu aplikacji wielodostępnej.
  2. Oprócz udostępniania zakresów/ról interfejsu API upewnij się, że rejestracja obejmuje uprawnienie "Logowanie i odczyt profilu użytkownika" (domyślnie dostępne).
  3. Zaimplementuj stronę logowania/rejestracji w kliencie sieci Web i postępuj zgodnie ze wskazówkami dotyczącymi zgody administratora .
  4. Gdy użytkownik wyraża zgodę na aplikację, linki jednostki usługi i delegowania zgody są tworzone w ich dzierżawie, a aplikacja natywna może uzyskać tokeny dla interfejsu API.

Poniższy diagram zawiera omówienie wyrażania zgody dla aplikacji wielowarstwowej zarejestrowanej w różnych dzierżawach.

Przedstawia zgodę na wielowarstwową aplikację wieloplatformową

Użytkownicy i Administratorzy mogą odwołać zgodę na aplikację w dowolnym momencie:

Jeśli administrator wyraża zgodę na aplikację dla wszystkich użytkowników w dzierżawie, użytkownicy nie mogą odwołać dostępu pojedynczo. Tylko administrator może odwołać dostęp i tylko dla całej aplikacji.

Aplikacje z wieloma dzierżawcami i buforowanie tokeny dostępu

Aplikacje z wieloma dzierżawcami mogą również uzyskać tokeny dostępu do wywoływania interfejsów API chronionych przez usługę Azure AD. Typowym błędem podczas korzystania z biblioteki Microsoft Authentication Library (MSAL) z aplikacją wielodostępną jest wstępne zażądanie tokenu dla użytkownika korzystającego z usługi/typowe, odebranie odpowiedzi, a następnie zażądanie kolejnego tokenu dla tego samego użytkownika również przy użyciu/Common. Ponieważ odpowiedź z usługi Azure AD pochodzi z dzierżawy, a nie/typowe, usługa MSAL buforuje token jako pochodzący z dzierżawy. Kolejne wywołanie/typowe w celu uzyskania tokenu dostępu dla użytkownika powoduje odrzucenie wpisu pamięci podręcznej, a użytkownik jest monitowany o ponowne zalogowanie. Aby uniknąć braku pamięci podręcznej, upewnij się, że kolejne wywołania dla już zalogowanego użytkownika są nawiązywane w punkcie końcowym dzierżawy.

Następne kroki

W tym artykule przedstawiono sposób tworzenia aplikacji, która może zalogować użytkownika z dowolnej dzierżawy usługi Azure AD. Po włączeniu jednego Sign-On (SSO) między aplikacją i usługą Azure AD możesz także zaktualizować aplikację, aby uzyskać dostęp do interfejsów API udostępnianych przez zasoby firmy Microsoft, takich jak Microsoft 365. Dzięki temu możesz oferować spersonalizowany interfejs w aplikacji, taki jak wyświetlanie informacji kontekstowych dla użytkowników, takich jak ich zdjęcie profilu lub termin następnego kalendarza.

Aby dowiedzieć się więcej na temat tworzenia wywołań interfejsu API w usłudze Azure AD i Microsoft 365 usług takich jak Exchange, SharePoint, OneDrive, OneNote i inne, odwiedź stronę Microsoft Graph API.