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. wszystkie nowo utworzone aplikacje usługi App Service będą miały możliwość wygenerowania unikatowej domyślnej nazwy hosta przy użyciu konwencji <app-name>-<random-hash>.<region>.azurewebsites.netnazewnictwa . Istniejące nazwy aplikacji pozostaną niezmienione.

Przykład: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Aby uzyskać więcej informacji, zapoznaj się z unikatową domyślną nazwą 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 najpierw zarejestrować ją w dzierżawie lub w 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, 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 polu Typ dzierżawy 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 biznesowych i klientów biznesowych.

Wybieranie rejestracji aplikacji

Funkcja uwierzytelniania usługi App Service może automatycznie utworzyć rejestrację aplikacji dla Ciebie 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.

Utwórz i użyj nowej rejestracji aplikacji lub użyj istniejącej rejestracji utworzonej oddzielnie.

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.

Wprowadź nazwę nowej rejestracji aplikacji.

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. Dotyczy to szkół i firm korzystających 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. Możesz zaktualizować to ustawienie później, aby użyć odwołań usługi Key Vault, jeśli chcesz zarządzać wpisem tajnym w usłudze Azure Key Vault.

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

Dowolny z następujących elementów:

  • Wybierz pozycję Wybierz istniejącą rejestrację aplikacji w tym katalogu i wybierz rejestrację aplikacji z listy rozwijanej.
  • Wybierz pozycję 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, postępuj zgodnie z przewodnikiem Szybki start dotyczący rejestrowania aplikacji . 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 pozwala na żądanie tokenów, które udzielają dostępu. Jest on używany jako prefiks 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 dowiedzieć się więcej na temat akceptowanych formatów identyfikatorów URI identyfikatorów aplikacji, zobacz dokumentację najlepszych rozwiązań dotyczących rejestracji aplikacji.

  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. W polach tekstowych wprowadź nazwę zakresu zgody i 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 przejściu z tej strony nie będzie ona ponownie wyświetlana.

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

Konfigurowanie dodatkowych testów

Skonfiguruj dodatkowe kontrole, które 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ąć dodatkowe 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, a domyślne opcje przekierują wszystkie żądania, aby zalogować się przy użyciu 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 dowiedzieć się więcej o tych opcjach, 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. Możesz to 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ę. Zostaną one dodane 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 zostanie wyświetlony 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 ten samouczek.

Autoryzowanie żądań

Domyślnie uwierzytelnianie usługi App Service obsługuje tylko uwierzytelnianie, określając, czy obiekt wywołujący jest tym, kim są. Autoryzacja, określenie, czy obiekt wywołujący powinien mieć dostęp do niektórych zasobów, to dodatkowy krok poza uwierzytelnianiem. Więcej informacji na temat tych pojęć można uzyskać w Platforma tożsamości Microsoft podstawach 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 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. Po skonfigurowaniu uwierzytelniania usługi App Service dla scenariusza z wieloma dzierżawami nie sprawdza, z której dzierżawy 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. Zapoznaj się ze wskazówkami dotyczącymi Platforma tożsamości Microsoft z wieloma dzierżawami.

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. 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 uzyskiwanie dostępu do aplikacji, co jest odpowiednie w przypadku wielu aplikacji. Jednak 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ę validation defaultAuthorizationPolicy , która może zawierać obiekt, jak w następującej strukturze:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Właściwości opis
defaultAuthorizationPolicy Grupowanie wymagań, które należy spełnić w celu uzyskania dostępu do aplikacji. 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 będą 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 dokumentację Platforma tożsamości Microsoft oświadczeń.
allowedPrincipals Grupowanie testów, które określają, czy podmiot zabezpieczeń reprezentowany przez przychodzące żądanie 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 dokumentację Platforma tożsamości Microsoft oświadczeń.

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 "aaaabb-0000-cccc-1111-dddd2222eeee") w celu wymagania, że token przychodzący pochodzi z jednej z określonych dzierżaw, zgodnie tid z oświadczeniem. Ustawienie WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL aplikacji można skonfigurować na wartość "true" lub "1", aby wymagać tokenu przychodzącego oid w celu uwzględnienia oświadczenia. To ustawienie jest ignorowane i traktowane jako prawda, jeśli allowedPrincipals.identities zostało skonfigurowane (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 firmie Microsoft Entra, aby mogli żądać dostępu do interfejsów API uwidocznionych przez usługę App Service w imieniu użytkowników lub siebie, takich jak architektura N-warstwowa. Wykonanie czynności opisanych w tej sekcji nie jest wymagane, jeśli chcesz uwierzytelnić użytkowników.

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.

  2. W obszarze nawigacji po lewej stronie wybierz pozycję Rejestracje aplikacji> Nowa rejestracja.

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

  4. W polu Identyfikator URI przekierowania wybierz pozycję Klient publiczny (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ę Uprawnienia>interfejsu API 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.

Teraz 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 (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.

  1. W menu portalu wybierz pozycję Microsoft Entra.
  2. W obszarze nawigacji po lewej stronie wybierz pozycję 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ę Certyfikaty i wpisy tajne Klienta Wpisy>tajne>Nowego klienta.
  8. Wprowadź opis i wygaśnięcie, a następnie wybierz pozycję Dodaj.
  9. W polu Wartość skopiuj wartość wpisu tajnego klienta. Po przejściu z tej strony nie będzie ona ponownie wyświetlana.

Teraz możesz zażądać tokenu dostępu przy użyciu identyfikatora klienta i klucza tajnego klienta, ustawiając resource 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, a uwierzytelnianie usługi App Service zweryfikuje i użyje tokenu tak jak zwykle, aby wskazać, że obiekt wywołujący (w tym przypadku aplikacja, a nie użytkownik) jest uwierzytelniony.

Obecnie pozwala to dowolnej aplikacji klienckiej w dzierżawie firmy Microsoft Entra zażądać tokenu dostępu i uwierzytelnić się 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 funkcję, 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, a następnie wybierz pozycję Dodaj uprawnienia.
  5. Upewnij się, że wybierz pozycję Udziel zgody administratora, aby autoryzować aplikację kliencą, aby zażądać uprawnień.
  6. 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 będzie zawierać roles oświadczenie zawierające role aplikacji, które zostały autoryzowane dla aplikacji klienckiej.
  7. W docelowym kodzie aplikacji App Service lub Funkcji można teraz sprawdzić, czy oczekiwane role znajdują się w tokenie (nie jest to wykonywane przez uwierzytelnianie usługi App Service). Aby uzyskać więcej informacji, zobacz Uzyskiwanie dostępu do oświadczeń użytkowników.

Teraz 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 przy użyciu 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 mogły być również skonfigurowane z zależnością od przestarzałego programu Azure AD Graph, który jest zaplanowany na pełne wycofanie. Na przykład kod aplikacji mógł wywołać usługę Azure AD Graph, aby sprawdzić członkostwo w grupie w ramach filtru autoryzacji w potoku oprogramowania pośredniczącego. Aplikacje powinny przejść do programu Microsoft Graph , postępując zgodnie ze wskazówkami dostarczonymi przez firmę Microsoft Entra w ramach procesu wycofywania usługi Azure AD Graph. W poniższych instrukcjach 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:

  1. Zaktualizuj adres URL wystawcy, aby uwzględnić sufiks "/v2.0", 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), będzie to znajdować się w tablicy additionalLoginParams .
    • Jeśli używasz interfejsu API w wersji 2 (/authsettingsV2), będzie to znajdować się w tablicy loginParameters .

    Należy usunąć dowolne odwołanie do "https://graph.windows.net", na przykład. Obejmuje resource to parametr (który nie jest obsługiwany przez punkt końcowy "/v2.0") lub zakresy, których konkretnie żądasz 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 będzie już żądać uprawnień do programu Azure AD Graph, a zamiast tego otrzyma token dla programu Microsoft Graph. Każde użycie tego tokenu z kodu aplikacji również musi zostać zaktualizowane zgodnie ze wskazówkami dostarczonymi przez firmę Microsoft Entra.

Następne kroki