Udostępnij za pośrednictwem

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

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

W tym artykule pokazano, jak skonfigurować uwierzytelnianie dla usługi Azure App Service lub Azure Functions, aby aplikacja logowała użytkowników za pomocą Microsoft identity platform (Microsoft Entra) jako dostawcy uwierzytelniania.

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

Zanim aplikacja będzie mogła logować użytkowników, musisz zarejestrować ją w tenantcie pracowniczym lub zewnętrznym. Jeśli udostępniasz aplikację pracownikom lub gościom biznesowym, zarejestruj aplikację w tenant pracowniczym. Jeśli Twoja aplikacja jest dla konsumentów 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ę Ustawienia>Uwierzytelnianie, a następnie wybierz pozycję Dodaj dostawcę tożsamości.

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

  4. W obszarze Wybierz dzierżawę dla aplikacji i jej użytkowników wybierz jedną z następujących pozycji:

    • Konfiguracja pracowników (bieżąca dzierżawa) dla pracowników i gości biznesowych
    • 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. Możesz też 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 są najczęstszymi przypadkami korzystania z 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, która zawiera twoją aplikację. Taka sytuacja zawsze ma miejsce, jeśli podczas wybierania dzierżawy wybrano konfigurację zewnętrzną.
  • Opcja utworzenia nowej rejestracji nie jest dostępna dla chmur dla instytucji rządowych.

Opcja 1. Tworzenie i używanie nowej rejestracji aplikacji

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

  2. W polu Nazwa wprowadź nazwę nowej rejestracji aplikacji.

  3. Wybierz wartość Obsługiwane typ konta :

    • Obecny najemca — pojedynczy najemca. 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 Microsoft Entra — wielodostępność. Konta w dowolnym katalogu organizacyjnym. Wszyscy użytkownicy z kontem służbowym lub szkolnym w systemie Microsoft mogą używać Twojej aplikacji lub interfejsu API. Te konta obejmują szkoły i firmy korzystające z usługi Office 365. Użyj tej opcji, jeśli Twoimi docelowymi odbiorcami są klienci biznesowi lub edukacyjni oraz aby umożliwić wielodostępność.
    • Dowolny katalog Microsoft Entra i osobiste konta Microsoft. Konta w dowolnym katalogu organizacyjnym i osobistych kontach Microsoft (na przykład Skype lub Xbox). Wszyscy użytkownicy z kontem służbowym lub osobistym kontem Microsoft mogą używać aplikacji lub interfejsu API. Obejmuje ona szkoły i firmy korzystające z usługi Office 365 oraz 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 zakres 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 Jeśli chcesz zarządzać sekretem w Azure Key Vault, możesz zaktualizować to ustawienie później, aby użyć odwołań do Key Vault. Alternatywnie można to zmienić, aby użyć tożsamości zamiast klucza tajnego klienta. Obsługa korzystania z tożsamości jest obecnie dostępna w wersji zapoznawczej.

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

Aby użyć istniejącej rejestracji, wybierz jedną z następujących opcji:

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

  • Podaj szczegóły istniejącej rejestracji aplikacji. Następnie podaj:

    • Identyfikator aplikacji (klienta).

    • Klucz tajny klienta (zalecane). Tajna wartość, której aplikacja używa do potwierdzenia swojej tożsamości podczas żądania tokenu. Ta wartość jest zapisywana w konfiguracji aplikacji jako ustawienie aplikacji slot-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órego nie zalecamy.

      Aplikację można również skonfigurować tak, aby używała tożsamości zamiast klucza tajnego klienta. Obsługa korzystania z tożsamości jest obecnie dostępna w wersji zapoznawczej.

    • Adres URL wystawcy. Ten adres URL ma postać <authentication-endpoint>/<tenant-id>/v2.0. Zastąp <authentication-endpoint>wartością punktu końcowego uwierzytelniania specyficzną dla środowiska chmury. Na przykład dzierżawca w globalnym środowisku Azure będzie używać https://sts.windows.net jako punktu końcowego uwierzytelniania.

Jeśli musisz ręcznie utworzyć rejestrację aplikacji w dzierżawie pracowniczej, zobacz Rejestrowanie aplikacji w platformie tożsamości Microsofta. 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 wprowadź identyfikator URI przekierowania. Na przykład wprowadź https://contoso.azurewebsites.net/.auth/login/aad/callback.

Teraz zmodyfikuj rejestrację aplikacji:

  1. W okienku po lewej stronie wybierz pozycję Eksponuj interfejs API>Dodaj>Zapisz. Ta wartość jednoznacznie identyfikuje aplikację, gdy jest używana jako zasób, co umożliwia żądanie tokenów, które przyznają dostęp. 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 najemcy. W przypadku aplikacji z wieloma dzierżawcami należy podać własny identyfikator URI. Aby uzyskać więcej informacji na temat akceptowanych formatów identyfikatorów URI aplikacji, zobacz Najlepsze praktyki zabezpieczeń dotyczące właściwości aplikacji w usłudze Microsoft Entra ID.

  2. Wybierz Dodaj zakres, a następnie:

    1. W 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 ma być widoczny dla użytkowników na stronie zgody. Na przykład wprowadź nazwę aplikacjiprogramu Access.
    4. Wybierz Dodaj zakres.

  3. (Zalecane) Utwórz asercję klienta dla aplikacji. Aby utworzyć klucz tajny klienta:

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

    Aplikację można również skonfigurować tak, aby używała tożsamości zamiast klucza tajnego klienta. Obsługa korzystania z tożsamości jest obecnie dostępna w wersji zapoznawczej.

  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 na stronie głównej Uwierzytelnianie , 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.

Dla wymagania najemcy wybierz, czy:

  • Zezwalaj na żądania tylko od najemcy wystawcy.
  • Zezwalaj na żądania z określonych dzierżawców.
  • Użyj domyślnych ograniczeń według wystawcy.

Aplikacja może nadal podjąć inne decyzje dotyczące autoryzacji w kodzie. Aby uzyskać więcej informacji, zobacz Używanie wbudowanych zasad autoryzacji w dalszej części tego artykułu.

Konfigurowanie ustawień uwierzytelniania

Ustawienia uwierzytelniania 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. To zachowanie można teraz dostosować lub dostosować te ustawienia później na stronie głównej Uwierzytelnianie , wybierając pozycję Edytuj obok pozycji Ustawienia uwierzytelniania. Aby uzyskać więcej informacji, zobacz Przepływ uwierzytelniania.

W obszarze Ograniczanie dostępu zdecyduj, czy:

  • Wymagaj uwierzytelniania.
  • Zezwalaj na nieuwierzytelniony dostęp.

W przypadku żądań niemających uwierzytelnienia, wybierz opcje w przypadku błędów:

  • HTTP 302 Found redirect: zalecane dla witryn internetowych
  • HTTP 401 Unauthorized: zalecane w przypadku interfejsów API
  • HTTP 403 Forbidden
  • HTTP 404 Not found

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 jeśli musisz zoptymalizować wydajność.

Dodaj dostawcę tożsamości

Jeśli wybrano konfigurację pracowników, możesz wybrać pozycję Dalej: Uprawnienia i dodać wszystkie uprawnienia programu Microsoft Graph, których potrzebuje aplikacja. 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 jesteś gotowy, aby użyć platformy tożsamości Microsoft do uwierzytelniania w twojej aplikacji. Dostawca znajduje się na stronie 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 w usłudze App Service zapewnia wbudowane kontrole, które mogą pomóc, ale same te elementy mogą nie być wystarczające, aby pokryć potrzeby autoryzacji aplikacji. W poniższych sekcjach omówiono te możliwości.

Wskazówka

Aplikacje wielodostępne powinny weryfikować wystawcę i identyfikator dzierżawcy żądania w ramach tego procesu, aby upewnić się, że wartości są dozwolone. Gdy uwierzytelnianie usługi App Service jest skonfigurowane dla scenariusza wielodostępności, nie weryfikuje, z której dzierżawy pochodzi żądanie. Aplikacja może być ograniczona do określonych dzierżawców, w zależności od tego, czy organizacja zarejestrowała się w usłudze (na przykład). Zobacz Zaktualizuj kod, aby obsługiwać wielu wystawców.

Wykonywanie walidacji z poziomu kodu aplikacji

Podczas przeprowadzania kontroli autoryzacji w kodzie aplikacji można wykorzystać informacje o roszczeniach udostępniane przez uwierzytelnianie 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 zakodowany w Base64 obiekt JSON z oświadczeniami dotyczącymi wywołującego. 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 przychodzące żądania dla dzierżawy 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 Microsoft Entra ma sekcję validation, która może zawierać obiekt defaultAuthorizationPolicy, jak pokazano w następującej strukturze:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Własność Opis
defaultAuthorizationPolicy Grupa wymagań, które muszą zostać spełnione 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. Gdy zarówno allowedApplications, jak i allowedPrincipals są skonfigurowane, żądania przychodzące muszą spełniać oba wymagania, aby zostać zaakceptowane.
allowedApplications Lista dozwolonych ciągów identyfikatorów klientów aplikacji reprezentujących zasób klienta wywołujący aplikację. Jeśli ta właściwość jest skonfigurowana jako niepusta tablica, akceptowane są tylko tokeny uzyskane przez aplikację określoną na liście.

Ta zasada ocenia roszczenie appid lub azp przychodzącego tokenu, który musi być tokenem dostępu. Zobacz Żądania ładunku.
allowedPrincipals Grupa sprawdzeń, która określa, czy podmiot zabezpieczeń, który reprezentuje przychodzące żądanie, może uzyskać dostęp do aplikacji. Satysfakcja allowedPrincipals opiera się na zależności logicznej OR od jego skonfigurowanych właściwości.
identities (w obszarze allowedPrincipals) Lista dozwolonych identyfikatorów obiektów, które reprezentują użytkowników lub aplikacje mające dostęp. Jeśli ta właściwość jest skonfigurowana jako niepusta tablica, wymaganie allowedPrincipals można spełnić, jeśli użytkownik lub aplikacja, którą reprezentuje żądanie, jest określona na liście. Istnieje limit 500 znaków (łącznie) na liście tożsamości.

Ta polityka ocenia roszczenie oid tokenu przychodzącego. Zobacz Żądania ładunku.

Ponadto można skonfigurować kontrole za pomocą ustawienia aplikacji, niezależnie od używanej wersji interfejsu API. Możesz skonfigurować ustawienie aplikacji WEBSITE_AUTH_AAD_ALLOWED_TENANTS przy użyciu listy identyfikatorów najemców oddzielonych przecinkami, o maksymalnej długości 10; na przykład aaaabbbb-0000-cccc-1111-dddd2222eeee. To ustawienie może wymagać, aby przychodzący token pochodził od jednego z określonych najemców, zgodnie z oświadczeniem tid.

Możesz skonfigurować ustawienie aplikacji w WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL na true lub 1, aby wymagać, aby przychodzący token zawierał oświadczenie oid. Jeśli skonfigurowano allowedPrincipals.identities, to ustawienie jest pomijane i traktowane jako prawdziwe, ponieważ roszczenie oid jest weryfikowane względem tej podanej listy tożsamości.

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

Użyj tożsamości zarządzanej zamiast tajemnicy (wersja zapoznawcza)

Zamiast konfigurować klucz tajny klienta na potrzeby rejestracji aplikacji, możesz skonfigurować aplikację tak, aby ufała tożsamości zarządzanej (wersja zapoznawcza). Użycie tożsamości zamiast sekretu oznacza, że nie musisz zarządzać tajemnicą. Nie musisz martwić się o wygaśnięcie tajemnicy i nie masz tego samego poziomu ryzyka wynikającego z potencjalnego ujawnienia lub wycieku tej tajemnicy.

Tożsamość umożliwia utworzenie poświadczenia tożsamości federacyjnej, które można użyć zamiast tajnego klucza klienta jako dowodu klienta. Takie podejście jest dostępne tylko w przypadku konfiguracji siły roboczej. Wbudowana funkcja uwierzytelniania obecnie obsługuje poświadczenia tożsamości federacyjnej jako wersję zapoznawczą.

Kroki opisane w tej sekcji umożliwiają skonfigurowanie zasobu usługi App Service lub usługi Azure Functions w celu użycia tego wzorca. Założono, że rejestracja aplikacji została już skonfigurowana przy użyciu jednej z obsługiwanych metod oraz że masz już zdefiniowany tajny klucz.

  1. Utwórz zasób tożsamości zarządzanej przypisanej użytkownikowi zgodnie z tymi instrukcjami.

  2. Przypisz tę tożsamość do zasobu App Service lub Azure Functions.

    Ważne

    Utworzona przez użytkownika tożsamość zarządzana powinna być przypisana tylko do aplikacji App Service lub Azure Functions za pośrednictwem tej rejestracji. Jeśli przypiszesz tożsamość do innego zasobu, dajesz temu zasobowi niepotrzebny dostęp do Twojej rejestracji aplikacji.

  3. Zanotuj wartości Identyfikator obiektu i Identyfikator klienta tożsamości zarządzanej. Identyfikator obiektu będzie potrzebny do utworzenia poświadczeń tożsamości federacyjnej w następnym kroku. W późniejszym kroku użyjesz identyfikatora klienta tożsamości zarządzanej.

  4. Postępuj zgodnie z instrukcjami dotyczącymi identyfikatora Entra firmy Microsoft, aby skonfigurować poświadczenie tożsamości federacyjnej w istniejącej aplikacji. Te instrukcje obejmują również sekcje dotyczące aktualizowania kodu aplikacji, które można pominąć.

  5. Dodaj nowe ustawienie aplikacji o nazwie OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Ustaw jej wartość na wartość identyfikatora klienta tożsamości zarządzanej uzyskaną w poprzednim kroku. Nie używaj identyfikatora klienta rejestracji aplikacji. Pamiętaj, aby oznaczyć to ustawienie aplikacji jako „slot-sticky” (czyli związane ze slotem).

  6. W wbudowanych ustawieniach uwierzytelniania dla zasobu aplikacji ustaw nazwę ustawienia Klucz tajny klienta na OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Aby wprowadzić tę zmianę przy użyciu witryny Azure Portal:

    1. Wróć do zasobu usługi App Service lub usługi Azure Functions i wybierz kartę Uwierzytelnianie .
    2. W sekcji Dostawca tożsamości, dla wpisu Microsoft, wybierz ikonę w kolumnie Edytuj.
    3. W oknie dialogowym Edytowanie dostawcy tożsamości otwórz listę rozwijaną w polu Nazwa ustawienia tajemnicy klienta i wybierz opcję OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
    4. Wybierz Zapisz.

    Aby wprowadzić tę zmianę przy użyciu interfejsu API REST:

    • Ustaw właściwość clientSecretSettingName na wartość OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Tę właściwość można znaleźć w obszarze properties>identityProviders>azureActiveDirectory>registration.

  7. Sprawdź, czy aplikacja działa zgodnie z oczekiwaniami. Powinno być możliwe pomyślne wykonanie nowej akcji logowania.

Gdy jesteś zadowolony z zachowania przy użyciu tożsamości zarządzanej, usuń istniejący sekret.

  1. Upewnij się, że kod aplikacji nie ma zależności od ustawienia aplikacji. Jeśli tak, postępuj zgodnie z instrukcjami, aby zaktualizować kod aplikacji, aby zażądać tokenu dostępu.

  2. Usuń ustawienie aplikacji, które wcześniej przechowywało twój sekret. Nazwa tego ustawienia aplikacji to poprzednia wartość ustawienia tajnego klucza klienta, przed jego zmianą na OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Zaloguj się do centrum administracyjnego Microsoft Entra, korzystając z dzierżawy zawierającej rejestrację aplikacji. Przejdź ponownie do rejestracji aplikacji.

  4. W obszarze Certyfikaty i wpisy tajne wybierz pozycję Wpisy tajne klienta i usuń klucz tajny klienta.

Aplikacja jest teraz skonfigurowana do używania uwierzytelniania Microsoft Entra ID bez przechowywania haseł.

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

W poprzednich sekcjach zarejestrowano aplikację App Service lub Azure Functions w celu uwierzytelniania użytkowników. W poniższych sekcjach opisano, jak zarejestrować klientów natywnych lub aplikacje daemon w usłudze Microsoft Entra. Ci klienci lub aplikacje mogą żądać dostępu do interfejsów API udostępnianych przez usługę App Service w imieniu użytkowników lub siebie, na przykład w architekturze N-warstwowej. Jeśli chcesz tylko uwierzytelnić użytkowników, kroki opisane w poniższych sekcjach nie są wymagane.

Natywna aplikacja kliencka

Możesz zarejestrować klientów lokalnych, aby zażądać dostępu do usług API aplikacji App Service na rzecz zalogowanego użytkownika.

  1. W menu witryny Azure Portal wybierz pozycję Microsoft Entra ID.

  2. W okienku po lewej stronie wybierz pozycję Zarządzaj>rejestracjami aplikacji. Następnie wybierz pozycję Nowa rejestracja.

  3. W okienku Rejestrowanie aplikacji w polu Nazwa wprowadź nazwę rejestracji aplikacji.

  4. W Redirect URI wybierz pozycję Klient publiczny/natywny (mobilny i stacjonarny) i wprowadź adres URL przekierowania. Na przykład wprowadź 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 zamiast URI.

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

  8. Wybierz rejestrację aplikacji utworzoną wcześniej dla aplikacji usługi App Service. Jeśli nie widzisz rejestracji aplikacji, upewnij się, że dodałeś zakres user_impersonation podczas rejestracji aplikacji.

  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 Azure Functions w imieniu samej aplikacji klienckiej, a nie w imieniu użytkownika. Ten scenariusz jest przydatny dla nieinterakcyjnych aplikacji demon, wykonujących 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 okienku po lewej stronie wybierz pozycję Zarządzaj>rejestracjami aplikacji. Następnie wybierz pozycję Nowa rejestracja.

  3. W okienku Rejestrowanie aplikacji w polu Nazwa wprowadź nazwę rejestracji aplikacji.

  4. W przypadku aplikacji demona nie potrzebujesz identyfikatora URI przekierowania, więc możesz pozostawić puste pole Identyfikator URI przekierowania .

  5. Wybierz pozycję Zarejestruj.

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

  7. W okienku po lewej stronie wybierz pozycję Zarządzaj>certyfikatami i wpisami tajnymi. Następnie wybierz 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ść tajemnicy 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 wartość identyfikatora URI aplikacji docelowej. Wynikowy token dostępu można następnie przedstawić aplikacji docelowej za pośrednictwem standardowego nagłówka autoryzacji OAuth 2.0. Uwierzytelnianie w usłudze App Service weryfikuje i używa tokenu, aby potwierdzić, że 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ę App Service lub Azure Functions, którą chcesz chronić.

  2. W rejestracji aplikacji, która reprezentuje klienta wymagającego autoryzacji, wybierz pozycję Uprawnienia interfejsu API, następnie >, a potem 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. Wybierz pozycję Udziel zgody administratora , aby autoryzować aplikację kliencją do żądania uprawnień.

    Podobnie jak w poprzednim scenariuszu (przed dodaniu dowolnych ról), możesz teraz zażądać tokenu dostępu dla tego samego zasobu docelowego. Token dostępu zawiera roles oświadczenie zawierające role aplikacji, które zostały autoryzowane dla aplikacji klienckiej.

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

Skonfigurowano teraz aplikację demona-klienta, która może uzyskiwać dostęp do usługi App Service używając własnej tożsamości.

Najlepsze rozwiązania

Niezależnie od konfiguracji używanej do konfigurowania uwierzytelniania, następujące najlepsze praktyki zapewniają większe bezpieczeństwo twojego dzierżawcy 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 usługi Azure AD Graph, która jest przestarzała i zaplanowana 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:

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

  • 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 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ąć wszelkie odwołania do elementu https://graph.windows.net, na przykład. Ta zmiana obejmuje resource parametr, którego /v2.0 punkt końcowy nie obsługuje. Zawiera również wszelkie zakresy, które zostały specjalnie żą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. W wielu przypadkach można użyć zakresu domyślnego , aby uprościć tę konfigurację. W tym celu dodaj nowy parametr logowania: scope=openid profile email https://graph.microsoft.com/.default.

Po wprowadzeniu tych zmian uwierzytelnianie usługi App Service, próbując 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.

Powiązana zawartość