Udostępnij za pośrednictwem

Konfigurowanie aplikacji App Service lub Azure Functions do korzystania z logowania w usłudze Microsoft Entra

  • Artykuł

Uwaga

Od 1 czerwca 2024 r. nowo utworzone aplikacje usługi App Service mogą wygenerować unikatową domyślną nazwę hosta, która używa konwencji <app-name>-<random-hash>.<region>.azurewebsites.netnazewnictwa . Istniejące nazwy aplikacji pozostają niezmienione. Na przykład:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Aby uzyskać więcej informacji, zobacz Unikatowa domyślna nazwa hosta zasobu usługi App Service.

Wybierz innego dostawcę uwierzytelniania, aby przejść do niego.

W tym artykule pokazano, jak skonfigurować uwierzytelnianie dla usługi aplikacja systemu Azure Service lub Azure Functions, aby aplikacja logować użytkowników za pomocą Platforma tożsamości Microsoft (Microsoft Entra) jako dostawcy uwierzytelniania.

Wybieranie dzierżawy dla aplikacji i jej użytkowników

Zanim aplikacja będzie mogła zalogować użytkowników, musisz zarejestrować ją w dzierżawie pracowników lub dzierżawie zewnętrznej. Jeśli udostępniasz aplikację pracownikom lub gościom biznesowym, zarejestruj aplikację w dzierżawie pracowników. Jeśli Twoja aplikacja jest dla klientów biznesowych i klientów biznesowych, zarejestruj ją w dzierżawie zewnętrznej.

  1. Zaloguj się do witryny Azure Portal i przejdź do aplikacji.

  2. W menu po lewej stronie aplikacji wybierz pozycję Uwierzytelnianie ustawień>, a następnie wybierz pozycję Dodaj dostawcę tożsamości.

  3. Na stronie Dodawanie dostawcy tożsamości wybierz pozycję Microsoft jako dostawcę tożsamości, aby zalogować się do tożsamości firmy Microsoft i tożsamości firmy Microsoft.

  4. W obszarze Wybierz dzierżawę dla aplikacji i jej użytkowników wybierz pozycję Konfiguracja pracowników (bieżąca dzierżawa) dla pracowników i gości biznesowych lub wybierz pozycję Konfiguracja zewnętrzna dla klientów i klientów biznesowych.

Wybieranie rejestracji aplikacji

Funkcja uwierzytelniania usługi App Service może automatycznie utworzyć rejestrację aplikacji lub użyć rejestracji utworzonej oddzielnie przez Ciebie lub administratora katalogu.

Utwórz nową rejestrację aplikacji automatycznie, chyba że musisz utworzyć rejestrację aplikacji oddzielnie. Jeśli chcesz, możesz później dostosować rejestrację aplikacji w centrum administracyjnym firmy Microsoft Entra.

Następujące sytuacje to najczęstsze przypadki użycia istniejącej rejestracji aplikacji:

  • Twoje konto nie ma uprawnień do tworzenia rejestracji aplikacji w dzierżawie firmy Microsoft Entra.
  • Chcesz użyć rejestracji aplikacji z innej dzierżawy firmy Microsoft Entra niż ta, w której znajduje się twoja aplikacja.
  • Opcja utworzenia nowej rejestracji nie jest dostępna dla chmur dla instytucji rządowych.

Możesz utworzyć i użyć nowej rejestracji aplikacji (opcja 1) lub użyć istniejącej rejestracji utworzonej oddzielnie (opcja 2).

Opcja 1. Tworzenie i używanie nowej rejestracji aplikacji

Użyj tej opcji, chyba że musisz utworzyć rejestrację aplikacji oddzielnie. Rejestrację aplikacji można dostosować w usłudze Microsoft Entra po jej utworzeniu.

Uwaga

Opcja automatycznego tworzenia nowej rejestracji nie jest dostępna dla chmur dla instytucji rządowych. Zamiast tego zdefiniuj rejestrację oddzielnie.

  1. Wybierz pozycję Utwórz nową rejestrację aplikacji.

  2. Wprowadź nazwę nowej rejestracji aplikacji.

  3. Wybierz typ obsługiwanego konta:

    • Bieżąca dzierżawa — pojedyncza dzierżawa. Tylko konta w tym katalogu organizacyjnym. Wszystkie konta użytkowników i gości w katalogu mogą używać aplikacji lub interfejsu API. Użyj tej opcji, jeśli docelowi odbiorcy są wewnętrzni w twojej organizacji.
    • Dowolny katalog Firmy Microsoft Entra — wielodostępny. Konta w dowolnym katalogu organizacyjnym. Wszyscy użytkownicy z kontem służbowym firmy Microsoft mogą używać aplikacji lub interfejsu API. Te konta obejmują szkoły i firmy korzystające z usługi Office 365. Użyj tej opcji, jeśli docelowi odbiorcy są klientami biznesowymi lub edukacyjnymi i umożliwiają wielodostępność.
    • Dowolny katalog Microsoft Entra i osobiste konta Microsoft. Konta w dowolnym katalogu organizacyjnym i osobistych kontach Microsoft (na przykład Skype, Xbox). Wszyscy użytkownicy z kontem służbowym lub osobistym Microsoft mogą używać aplikacji lub interfejsu API. Obejmuje ona szkoły i firmy korzystające z usługi Office 365, a także konta osobiste używane do logowania się do usług, takich jak Xbox i Skype. Użyj tej opcji, aby określić najszerszy zestaw tożsamości firmy Microsoft i włączyć wielodostępność.
    • Tylko osobiste konta Microsoft. Konta osobiste używane do logowania się do usług, takich jak Xbox i Skype. Użyj tej opcji, aby określić najszerszy zestaw tożsamości firmy Microsoft.

Jeśli chcesz, możesz później zmienić nazwę rejestracji lub obsługiwane typy kont.

Wpis tajny klienta jest tworzony jako ustawienie aplikacji slot-sticky o nazwie MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Jeśli chcesz zarządzać wpisem tajnym w usłudze Azure Key Vault, możesz zaktualizować to ustawienie później, aby użyć odwołań usługi Key Vault.

Opcja 2. Użyj istniejącej rejestracji utworzonej oddzielnie

Wybierz jedną z następujących pozycji:

  • Wybierz istniejącą rejestrację aplikacji w tym katalogu i wybierz rejestrację aplikacji z listy rozwijanej.

  • Podaj szczegóły istniejącej rejestracji aplikacji i podaj następujące informacje:

    • Identyfikator aplikacji (klienta).
    • Klucz tajny klienta (zalecane). Wartość wpisu tajnego używana przez aplikację do potwierdzenia tożsamości podczas żądania tokenu. Ta wartość jest zapisywana w konfiguracji aplikacji jako ustawienie aplikacji sticky o nazwie MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Jeśli klucz tajny klienta nie jest ustawiony, operacje logowania z usługi korzystają z niejawnego przepływu udzielania OAuth 2.0, który nie jest zalecany.
    • Adres URL wystawcy, który ma postać <authentication-endpoint>/<tenant-id>/v2.0. Zastąp <authentication-endpoint> element wartością punktu końcowego uwierzytelniania specyficzną dla środowiska chmury. Na przykład dzierżawa pracowników na globalnej platformie Azure używahttps://sts.windows.net" "; jako punkt końcowy uwierzytelniania.

Jeśli musisz ręcznie utworzyć rejestrację aplikacji w dzierżawie pracowników, zobacz Rejestrowanie aplikacji przy użyciu Platforma tożsamości Microsoft. Podczas procesu rejestracji pamiętaj, aby zanotować identyfikator aplikacji (klienta) i wartości wpisów tajnych klienta.

Podczas procesu rejestracji w sekcji Identyfikatory URI przekierowania wybierz pozycję Sieć Web dla platformy i wpisz <app-url>/.auth/login/aad/callback. Na przykład https://contoso.azurewebsites.net/.auth/login/aad/callback.

Po utworzeniu zmodyfikuj rejestrację aplikacji:

  1. W obszarze nawigacji po lewej stronie wybierz pozycję Uwidaczniaj interfejs API>Dodaj>zapisz. Ta wartość unikatowo identyfikuje aplikację, gdy jest używana jako zasób, co umożliwia zażądanie tokenów, które udzielają dostępu. Wartość jest prefiksem dla tworzonych zakresów.

    W przypadku aplikacji z jedną dzierżawą można użyć wartości domyślnej, która znajduje się w postaci api://<application-client-id>. Można również określić bardziej czytelny identyfikator URI, taki jak https://contoso.com/api na podstawie jednej ze zweryfikowanych domen dla dzierżawy. W przypadku aplikacji wielodostępnej należy podać niestandardowy identyfikator URI. Aby uzyskać więcej informacji na temat akceptowanych formatów identyfikatorów URI identyfikatorów aplikacji, zobacz Security best practices for application properties in Microsoft Entra ID (Najlepsze rozwiązania w zakresie zabezpieczeń dotyczące właściwości aplikacji w identyfikatorze Entra firmy Microsoft).

  2. Wybierz Dodaj zakres.

    1. W polu Nazwa zakresu wprowadź user_impersonation.
    2. W obszarze Kto może wyrazić zgodę, wybierz pozycję Administratorzy i użytkownicy , jeśli chcesz zezwolić użytkownikom na wyrażanie zgody na ten zakres.
    3. Wprowadź nazwę zakresu zgody. Wprowadź opis, który użytkownicy mają zobaczyć na stronie zgody. Na przykład wprowadź nazwę aplikacji> programu Access<.
    4. Wybierz Dodaj zakres.

  3. (Zalecane) Aby utworzyć klucz tajny klienta:

    1. W obszarze nawigacji po lewej stronie wybierz pozycję Certyfikaty i wpisy tajne Klienta Wpisy>tajne>Nowego klienta.
    2. Wprowadź opis i wygaśnięcie, a następnie wybierz pozycję Dodaj.
    3. W polu Wartość skopiuj wartość wpisu tajnego klienta. Po odejściu od tej strony nie zostanie ona ponownie wyświetlona.

  4. (Opcjonalnie) Aby dodać wiele adresów URL odpowiedzi, wybierz pozycję Uwierzytelnianie.

Konfigurowanie dodatkowych testów

Dodatkowe kontrole określają, które żądania mogą uzyskiwać dostęp do aplikacji. To zachowanie można teraz dostosować lub dostosować te ustawienia później z głównego ekranu uwierzytelniania , wybierając pozycję Edytuj obok pozycji Ustawienia uwierzytelniania.

W przypadku wymagania aplikacji klienckiej wybierz, czy:

  • Zezwalaj na żądania tylko z tej aplikacji
  • Zezwalaj na żądania z określonych aplikacji klienckich
  • Zezwalaj na żądania z dowolnej aplikacji (niezalecane)

W obszarze Wymaganie dotyczące tożsamości wybierz, czy:

  • Zezwalaj na żądania z dowolnej tożsamości
  • Zezwalaj na żądania z określonych tożsamości

W obszarze Wymaganie dotyczące dzierżawy wybierz, czy:

  • Zezwalaj na żądania tylko z dzierżawy wystawcy
  • Zezwalaj na żądania z określonych dzierżaw
  • Używanie ograniczeń domyślnych na podstawie wystawcy

Aplikacja może nadal podjąć inne decyzje dotyczące autoryzacji w kodzie. Aby uzyskać więcej informacji, zobacz Używanie wbudowanych zasad autoryzacji.

Konfigurowanie ustawień uwierzytelniania

Te opcje określają sposób, w jaki aplikacja odpowiada na nieuwierzytelnione żądania. Domyślne opcje przekierowują wszystkie żądania, aby zalogować się za pomocą tego nowego dostawcy. Możesz teraz zmienić to zachowanie lub dostosować te ustawienia później z głównego ekranu uwierzytelniania , wybierając pozycję Edytuj obok pozycji Ustawienia uwierzytelniania. Aby uzyskać więcej informacji, zobacz Przepływ uwierzytelniania.

W obszarze Ograniczanie dostępu zdecyduj, czy:

  • Wymaganie uwierzytelniania
  • Zezwalaj na nieuwierzytelniony dostęp

W przypadku nieuwierzytelnionych żądań

  • Znaleziono przekierowanie HTTP 302: zalecane w przypadku witryn internetowych
  • HTTP 401 Brak autoryzacji: zalecane w przypadku interfejsów API
  • HTTP 403 Zabronione
  • Nie znaleziono protokołu HTTP 404

Wybierz pozycję Magazyn tokenów (zalecane). Magazyn tokenów zbiera, przechowuje i odświeża tokeny dla aplikacji. To zachowanie można wyłączyć później, jeśli aplikacja nie potrzebuje tokenów lub musisz zoptymalizować wydajność.

Dodawanie dostawcy tożsamości

Jeśli wybrano konfigurację pracowników, możesz wybrać pozycję Dalej: Uprawnienia i dodać wszystkie uprawnienia programu Microsoft Graph wymagane przez aplikację. Te uprawnienia są dodawane do rejestracji aplikacji, ale można je również zmienić później. W przypadku wybrania konfiguracji zewnętrznej możesz później dodać uprawnienia programu Microsoft Graph.

  • Wybierz Dodaj.

Teraz możesz użyć Platforma tożsamości Microsoft do uwierzytelniania w aplikacji. Dostawca jest wyświetlany na ekranie Uwierzytelnianie . Z tego miejsca możesz edytować lub usunąć tę konfigurację dostawcy.

Aby zapoznać się z przykładem konfigurowania logowania microsoft Entra dla aplikacji internetowej, która uzyskuje dostęp do usługi Azure Storage i programu Microsoft Graph, zobacz Dodawanie uwierzytelniania aplikacji do aplikacji internetowej.

Autoryzowanie żądań

Domyślnie uwierzytelnianie usługi App Service obsługuje tylko uwierzytelnianie. Określa, czy rozmówcą jest to, kim mówią, że są. Autoryzacja, określająca, czy obiekt wywołujący powinien mieć dostęp do niektórych zasobów, jest krokiem wykraczającym poza uwierzytelnianie. Aby uzyskać więcej informacji, zobacz Podstawy autoryzacji.

Aplikacja może podejmować decyzje dotyczące autoryzacji w kodzie. Uwierzytelnianie usługi App Service zapewnia wbudowane kontrole, które mogą pomóc, ale same w sobie mogą nie być wystarczające, aby pokryć potrzeby autoryzacji aplikacji.

Napiwek

Aplikacje wielodostępne powinny weryfikować wystawcę i identyfikator dzierżawy żądania w ramach tego procesu, aby upewnić się, że wartości są dozwolone. Gdy uwierzytelnianie usługi App Service jest skonfigurowane dla scenariusza wielodostępnego, nie weryfikuje dzierżawy, z której pochodzi żądanie. Aplikacja może być ograniczona do określonych dzierżaw, na podstawie tego, czy organizacja zarejestrowała się w usłudze, na przykład. Zobacz Aktualizowanie kodu w celu obsługi wielu wartości wystawców.

Wykonywanie walidacji z poziomu kodu aplikacji

Podczas przeprowadzania kontroli autoryzacji w kodzie aplikacji można użyć informacji o oświadczeniach udostępnianych przez uwierzytelnianie usługi App Service. Aby uzyskać więcej informacji, zobacz Uzyskiwanie dostępu do oświadczeń użytkowników w kodzie aplikacji.

Wstrzykiwany x-ms-client-principal nagłówek zawiera obiekt JSON zakodowany w formacie Base64 z oświadczeniami określonymi w obiekcie wywołującym. Domyślnie te oświadczenia przechodzą przez mapowanie oświadczeń, więc nazwy oświadczeń mogą nie zawsze być zgodne z tym, co można zobaczyć w tokenie. Na przykład oświadczenie tid jest mapowane na http://schemas.microsoft.com/identity/claims/tenantid zamiast tego.

Możesz również pracować bezpośrednio z bazowym tokenem dostępu z wstrzykniętego x-ms-token-aad-access-token nagłówka.

Korzystanie z wbudowanych zasad autoryzacji

Utworzona rejestracja aplikacji uwierzytelnia żądania przychodzące dla dzierżawy firmy Microsoft Entra. Domyślnie umożliwia ona również każdemu w dzierżawie dostęp do aplikacji. Takie podejście jest odpowiednie w przypadku wielu aplikacji. Niektóre aplikacje muszą jeszcze bardziej ograniczyć dostęp, podejmując decyzje dotyczące autoryzacji. Kod aplikacji jest często najlepszym miejscem do obsługi niestandardowej logiki autoryzacji. Jednak w przypadku typowych scenariuszy Platforma tożsamości Microsoft zapewnia wbudowane kontrole, których można użyć do ograniczenia dostępu.

W tej sekcji pokazano, jak włączyć wbudowane kontrole przy użyciu interfejsu API uwierzytelniania usługi App Service w wersji 2. Obecnie jedynym sposobem skonfigurowania tych wbudowanych testów jest użycie szablonów usługi Azure Resource Manager lub interfejsu API REST.

W obiekcie interfejsu API konfiguracja dostawcy tożsamości Firmy Microsoft Entra zawiera sekcję validationdefaultAuthorizationPolicy , która może zawierać obiekt, jak w następującej strukturze:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Właściwości opis
defaultAuthorizationPolicy Aby uzyskać dostęp do aplikacji, należy spełnić grupę wymagań. Dostęp jest udzielany w oparciu o wartość logiczną AND dla każdej ze skonfigurowanych właściwości. Po allowedApplications skonfigurowaniu i allowedPrincipals skonfigurowaniu żądania przychodzące musi spełniać oba wymagania, aby można je było zaakceptować.
allowedApplications Lista dozwolonych identyfikatorów klienta aplikacji ciągu reprezentujących zasób klienta wywołujący aplikację. Jeśli ta właściwość jest skonfigurowana jako tablica nonempty, akceptowane są tylko tokeny uzyskane przez aplikację określoną na liście.

Te zasady oceniają appid oświadczenia lub azp tokenu przychodzącego, który musi być tokenem dostępu. Zobacz Oświadczenia ładunku.
allowedPrincipals Grupa kontroli, która określa, czy podmiot zabezpieczeń reprezentowany przez żądanie przychodzące może uzyskać dostęp do aplikacji. Satysfakcja wynika z allowedPrincipals tego, że wartość jest oparta na wartości logicznej OR względem skonfigurowanych właściwości.
identities (w obszarze allowedPrincipals) Lista dozwolonych identyfikatorów obiektów ciągów reprezentujących użytkowników lub aplikacje, które mają dostęp. Jeśli ta właściwość jest skonfigurowana jako tablica nonempty, wymaganie może być spełnione, allowedPrincipals jeśli użytkownik lub aplikacja reprezentowana przez żądanie jest określona na liście. Na liście tożsamości jest łącznie 500 znaków.

Te zasady oceniają oid oświadczenie tokenu przychodzącego. Zobacz Oświadczenia ładunku.

Ponadto niektóre testy można skonfigurować za pomocą ustawienia aplikacji, niezależnie od używanej wersji interfejsu API. Ustawienie WEBSITE_AUTH_AAD_ALLOWED_TENANTS aplikacji można skonfigurować z rozdzielaną przecinkami listą maksymalnie 10 identyfikatorów dzierżawy, na przykład aaaabbbb-0000-cccc-1111-dddd2222eeee.

To ustawienie może wymagać, aby token przychodzący pochodzi z jednej z określonych dzierżaw, zgodnie z oświadczeniem tid . Ustawienie WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL aplikacji można skonfigurować na wartość true lub 1 wymagać tokenu przychodzącego oid w celu uwzględnienia oświadczenia. Jeśli allowedPrincipals.identities to ustawienie zostało skonfigurowane, jest ignorowane i traktowane jako prawda, ponieważ oid oświadczenie jest sprawdzane względem tej udostępnionej listy tożsamości.

Żądania, które kończą się niepowodzeniem tych wbudowanych testów, otrzymują odpowiedź HTTP 403 Forbidden .

Konfigurowanie aplikacji klienckich w celu uzyskania dostępu do usługi App Service

W poprzednich sekcjach zarejestrowano usługę App Service lub funkcję platformy Azure w celu uwierzytelnienia użytkowników. W tej sekcji opisano sposób rejestrowania natywnych klientów lub aplikacji demona w usłudze Microsoft Entra. Mogą żądać dostępu do interfejsów API udostępnianych przez usługę App Service w imieniu użytkowników lub siebie, takich jak architektura N-warstwowa. Jeśli chcesz tylko uwierzytelnić użytkowników, kroki opisane w tej sekcji nie są wymagane.

Natywna aplikacja kliencka

Możesz zarejestrować klientów natywnych, aby zażądać dostępu do interfejsów API aplikacji usługi App Service w imieniu zalogowanego użytkownika.

  1. W menu portalu wybierz pozycję Microsoft Entra ID.

  2. W obszarze nawigacji po lewej stronie wybierz pozycję Zarządzaj> Rejestracje aplikacji a następnie wybierz pozycję Nowa rejestracja.

  3. Na stronie Rejestrowanie aplikacji wprowadź nazwę rejestracji aplikacji.

  4. W polu Identyfikator URI przekierowania wybierz pozycję Klient publiczny/natywny (mobilny i klasyczny) i wpisz adres URL <app-url>/.auth/login/aad/callback. Na przykład https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Wybierz pozycję Zarejestruj.

  6. Po utworzeniu rejestracji aplikacji skopiuj wartość identyfikatora aplikacji (klienta).

    Uwaga

    W przypadku aplikacji ze sklepu Microsoft Store użyj identyfikatora SID pakietu jako identyfikatora URI.

  7. W obszarze nawigacji po lewej stronie wybierz pozycję Zarządzaj uprawnieniami> interfejsu API. Następnie wybierz pozycję Dodaj uprawnienie>Moje interfejsy API.

  8. Wybierz rejestrację aplikacji utworzoną wcześniej dla aplikacji usługi App Service. Jeśli rejestracja aplikacji nie jest widoczna, upewnij się, że w rejestracji aplikacji dodano zakres user_impersonation .

  9. W obszarze Uprawnienia delegowane wybierz pozycję user_impersonation, a następnie wybierz pozycję Dodaj uprawnienia.

Skonfigurowano natywną aplikację kliencką, która może żądać dostępu do aplikacji usługi App Service w imieniu użytkownika.

Aplikacja kliencka demona (wywołania typu service-to-service)

W architekturze N-warstwowej aplikacja kliencka może uzyskać token w celu wywołania aplikacji App Service lub funkcji w imieniu samej aplikacji klienckiej, a nie w imieniu użytkownika. Ten scenariusz jest przydatny w przypadku aplikacji demonów nieinterakcyjnych, które wykonują zadania bez zalogowanego użytkownika. Używa ona standardowego przyznawania poświadczeń klienta OAuth 2.0. Aby uzyskać więcej informacji, zobacz Platforma tożsamości Microsoft i przepływ poświadczeń klienta OAuth 2.0.

  1. W menu witryny Azure Portal wybierz pozycję Microsoft Entra ID.
  2. W obszarze nawigacji po lewej stronie wybierz pozycję Zarządzaj> Rejestracje aplikacji> Nowa rejestracja.
  3. Na stronie Rejestrowanie aplikacji wprowadź nazwę rejestracji aplikacji.
  4. W przypadku aplikacji demona nie potrzebujesz identyfikatora URI przekierowania, aby zachować ten pusty identyfikator.
  5. Wybierz pozycję Zarejestruj.
  6. Po utworzeniu rejestracji aplikacji skopiuj wartość identyfikatora aplikacji (klienta).
  7. W obszarze nawigacji po lewej stronie wybierz pozycję Zarządzaj>certyfikatami i wpisami tajnymi. Następnie wybierz pozycję Wpisy>tajne klienta Nowy klucz tajny klienta.
  8. Wprowadź opis i wygaśnięcie, a następnie wybierz pozycję Dodaj.
  9. W polu Wartość skopiuj wartość wpisu tajnego klienta. Po odejściu od tej strony nie zostanie ona ponownie wyświetlona.

Teraz możesz zażądać tokenu dostępu przy użyciu identyfikatora klienta i klucza tajnego klienta. resource Ustaw parametr na identyfikator URI identyfikatora aplikacji docelowej. Wynikowy token dostępu można następnie przedstawić aplikacji docelowej przy użyciu standardowego nagłówka autoryzacji OAuth 2.0. Uwierzytelnianie usługi App Service weryfikuje i używa tokenu jak zwykle, aby teraz wskazać, że obiekt wywołujący jest uwierzytelniony. W takim przypadku obiekt wywołujący jest aplikacją, a nie użytkownikiem.

Takie podejście umożliwia każdej aplikacji klienckiej w dzierżawie firmy Microsoft Entra żądanie tokenu dostępu i uwierzytelnianie w aplikacji docelowej. Jeśli chcesz również wymusić autoryzację , aby zezwolić tylko na niektóre aplikacje klienckie, musisz wykonać dodatkową konfigurację.

  1. Zdefiniuj rolę aplikacji w manifeście rejestracji aplikacji reprezentującej aplikację usługi App Service lub aplikację funkcji, którą chcesz chronić.

  2. W rejestracji aplikacji reprezentującej klienta, który musi być autoryzowany, wybierz pozycję Uprawnienia>interfejsu API Dodaj uprawnienie>Moje interfejsy API.

  3. Wybierz utworzoną wcześniej rejestrację aplikacji. Jeśli rejestracja aplikacji nie jest widoczna, upewnij się, że dodano rolę aplikacji.

  4. W obszarze Uprawnienia aplikacji wybierz utworzoną wcześniej rolę aplikacji. Wybierz opcję Dodaj uprawnienia.

  5. Upewnij się, że wybierz pozycję Udziel zgody administratora, aby autoryzować aplikację kliencą, aby zażądać uprawnień.

    Podobnie jak w poprzednim scenariuszu (przed dodaniem wszystkich ról), można teraz zażądać tokenu dostępu dla tego samego obiektu docelowego resource, a token dostępu zawiera roles oświadczenie zawierające role aplikacji, które zostały autoryzowane dla aplikacji klienckiej.

W docelowym kodzie aplikacji usługi App Service lub funkcji można teraz sprawdzić, czy oczekiwane role znajdują się w tokenie. Uwierzytelnianie usługi App Service nie wykonuje tej walidacji. Aby uzyskać więcej informacji, zobacz Uzyskiwanie dostępu do oświadczeń użytkowników.

Skonfigurowano aplikację kliencką demona, która może uzyskiwać dostęp do aplikacji usługi App Service przy użyciu własnej tożsamości.

Najlepsze rozwiązania

Niezależnie od konfiguracji używanej do konfigurowania uwierzytelniania, następujące najlepsze rozwiązania pozwalają zapewnić bezpieczeństwo dzierżawy i aplikacji:

  • Skonfiguruj każdą aplikację usługi App Service przy użyciu własnej rejestracji aplikacji w usłudze Microsoft Entra.
  • Nadaj każdej aplikacji usługi App Service własne uprawnienia i zgodę.
  • Unikaj udostępniania uprawnień między środowiskami. Użyj oddzielnych rejestracji aplikacji dla oddzielnych miejsc wdrożenia. Podczas testowania nowego kodu ta praktyka może pomóc zapobiec problemom wpływającym na aplikację produkcyjną.

Migrowanie do programu Microsoft Graph

Niektóre starsze aplikacje można skonfigurować z zależnością od przestarzałego programu Azure AD Graph, który jest zaplanowany na pełne wycofanie. Na przykład kod aplikacji może wywołać program Azure AD Graph, aby sprawdzić członkostwo w grupie w ramach filtru autoryzacji w potoku oprogramowania pośredniczącego. Aplikacje powinny zostać przeniesione do programu Microsoft Graph. Aby uzyskać więcej informacji, zobacz Migrowanie aplikacji z usługi Azure AD Graph do programu Microsoft Graph.

Podczas tej migracji może być konieczne wprowadzenie pewnych zmian w konfiguracji uwierzytelniania usługi App Service. Po dodaniu uprawnień programu Microsoft Graph do rejestracji aplikacji możesz wykonać następujące czynności:

  1. Zaktualizuj adres URL wystawcy, aby uwzględnić /v2.0 sufiks, jeśli jeszcze tego nie zrobiono.

  2. Usuń żądania uprawnień usługi Azure AD Graph z konfiguracji logowania. Właściwości do zmiany zależą od używanej wersji interfejsu API zarządzania:

    • Jeśli używasz interfejsu API w wersji 1 (/authsettings), to ustawienie znajduje się w tablicy additionalLoginParams .
    • Jeśli używasz interfejsu API w wersji 2 (/authsettingsV2), to ustawienie znajduje się w tablicy loginParameters .

    Musisz usunąć dowolne odwołanie do https://graph.windows.netelementu , na przykład. Ta zmiana obejmuje resource parametr, który nie jest obsługiwany przez /v2.0 punkt końcowy, ani zakresy, które zostały w szczególności żądane z usługi Azure AD Graph.

    Należy również zaktualizować konfigurację, aby zażądać nowych uprawnień programu Microsoft Graph skonfigurowanych na potrzeby rejestracji aplikacji. Aby uprościć tę konfigurację w wielu przypadkach, możesz użyć zakresu domyślnego. W tym celu dodaj nowy parametr scope=openid profile email https://graph.microsoft.com/.defaultlogowania .

Dzięki tym zmianom, gdy uwierzytelnianie usługi App Service próbuje się zalogować, nie żąda już uprawnień do usługi Azure AD Graph. Zamiast tego pobiera token dla programu Microsoft Graph. Wszelkie użycie tego tokenu z kodu aplikacji należy również zaktualizować zgodnie z opisem w temacie Migrowanie aplikacji z programu Azure AD Graph do programu Microsoft Graph.

Następne kroki