Uwierzytelnianie i autoryzacja w usłudze Azure Container Apps

Usługa Azure Container Apps udostępnia wbudowane funkcje uwierzytelniania i autoryzacji (czasami określane jako „Easy Auth”), które umożliwiają zabezpieczenie aplikacji kontenerowej udostępnianej na zewnątrz, z włączonym ruchem przychodzącym, przy użyciu minimalnej ilości kodu lub bez pisania kodu.

Aby uzyskać szczegółowe informacje dotyczące uwierzytelniania i autoryzacji, zapoznaj się z następującymi przewodnikami dotyczącymi wybranego dostawcy.

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• X
• Custom OpenID Connect

Dlaczego warto używać wbudowanego uwierzytelniania?

Nie musisz używać tej funkcji do uwierzytelniania i autoryzacji. Możesz użyć powiązanych funkcji zabezpieczeń w wybranej strukturze internetowej lub pisać własne narzędzia. Jednak zaimplementowanie bezpiecznego rozwiązania do uwierzytelniania (użytkowników logowania) i autoryzacji (zapewnienie dostępu do bezpiecznych danych) może wymagać znacznego nakładu pracy. Należy pamiętać, aby postępować zgodnie z najlepszymi rozwiązaniami i standardami branżowymi oraz zapewnić aktualność implementacji.

Wbudowana funkcja uwierzytelniania dla usługi Container Apps pozwala zaoszczędzić czas i nakład pracy dzięki udostępnieniu gotowego uwierzytelniania dostawcom tożsamości federacyjnych. Te funkcje pozwalają skupić się na większym czasie na tworzeniu aplikacji i krótszym czasie na tworzeniu systemów zabezpieczeń.

Korzyści:

• Usługa Azure Container Apps zapewnia dostęp do różnych wbudowanych dostawców uwierzytelniania.
• Wbudowane funkcje uwierzytelniania nie wymagają żadnego konkretnego języka, zestawu SDK, wiedzy na temat zabezpieczeń, a nawet jakiegokolwiek kodu, który trzeba napisać.
• Możesz zintegrować z wieloma dostawcami, w tym Microsoft Entra ID, Facebook, Google i X.

Dostawcy tożsamości

Usługa Container Apps używa tożsamości federacyjnej, w ramach której zewnętrzny dostawca tożsamości zarządza tożsamościami użytkowników i procesem uwierzytelniania za Ciebie. Domyślnie są dostępni następujący dostawcy tożsamości:

Jeśli używasz jednego z tych dostawców, punkt końcowy logowania jest dostępny na potrzeby uwierzytelniania użytkownika i weryfikacji tokenu uwierzytelniania od dostawcy. Możesz udostępnić swoim użytkownikom dowolną liczbę tych opcji dostawcy.

Zagadnienia dotyczące używania wbudowanego uwierzytelniania

Ta funkcja powinna być używana tylko z protokołem HTTPS. Upewnij się, że w konfiguracji ruchu przychodzącego dla aplikacji kontenera opcja allowInsecure jest wyłączona.

Aplikację kontenerową można skonfigurować na potrzeby uwierzytelniania z ograniczeniem dostępu do zawartości witryny i interfejsów API lub bez takiego ograniczenia. Aby ograniczyć dostęp aplikacji tylko do uwierzytelnionych użytkowników, ustaw ustawienie Ogranicz dostęp na wymaganie uwierzytelniania. Aby uwierzytelnić się, ale nie ograniczać dostępu, ustaw ustawienie Ogranicz dostęp na Zezwalaj na nieuwierzytelniony dostęp.

Domyślnie każda aplikacja kontenera wystawia własny unikatowy plik cookie lub token do uwierzytelniania. Możesz również podać własne klucze podpisywania i szyfrowania.

Architektura funkcji

Składnik pośredniczący uwierzytelniania i autoryzacji to funkcja platformy, która działa jako kontener sidecar przy każdej replice aplikacji. Po włączeniu aplikacja obsługuje każde przychodzące żądanie HTTP po przejściu przez warstwę zabezpieczeń.

Oprogramowanie pośredniczące platformy obsługuje kilka rzeczy dla aplikacji:

• Uwierzytelnia użytkowników i klientów przy użyciu określonych dostawców tożsamości
• Zarządza uwierzytelnianą sesją
• Wprowadza informacje o tożsamości do nagłówków żądań HTTP

Moduł uwierzytelniania i autoryzacji jest uruchamiany w oddzielnym kontenerze izolowanym od kodu aplikacji. Ponieważ kontener zabezpieczeń nie działa w procesie, nie jest możliwa bezpośrednia integracja z określonymi strukturami językowymi. Jednak istotne informacje wymagane przez aplikację są udostępniane w nagłówkach żądań zgodnie z opisem w tym artykule.

Przepływ uwierzytelniania

Przepływ uwierzytelniania jest taki sam dla wszystkich dostawców, ale różni się w zależności od tego, czy chcesz zalogować się przy użyciu zestawu SDK dostawcy:

• Bez pakietu SDK dostawcy (przepływ kierowany przez serwer lub przepływ serwera): aplikacja powierza logowanie federacyjne usłudze Container Apps. Delegacja jest zazwyczaj typowa dla aplikacji przeglądarkowych, które wyświetlają użytkownikowi stronę logowania dostawcy.

• Z użyciem zestawu SDK dostawcy (przepływ sterowany przez klienta lub przepływ klienta): aplikacja ręcznie loguje użytkowników u dostawcy, a następnie przesyła token uwierzytelniania do usługi Container Apps do zweryfikowania. Takie podejście jest typowe w przypadku aplikacji bez przeglądarki, które nie prezentują strony logowania dostawcy do użytkownika. Przykładem jest natywna aplikacja mobilna, która loguje użytkowników przy użyciu zestawu SDK dostawcy.

Wywołania z zaufanej aplikacji przeglądarkowej w usłudze Container Apps do innego interfejsu API REST w usłudze Container Apps mogą być uwierzytelniane przy użyciu przepływu sterowanego przez serwer. Aby uzyskać więcej informacji, zobacz Dostosowywanie logowania i wylogowywanie.

W tabeli przedstawiono kroki przepływu uwierzytelniania.

W przypadku przeglądarek klienckich usługa Container Apps może automatycznie kierować wszystkich nieuwierzytelnionych użytkowników do usługi /.auth/login/<PROVIDER>. Możesz również przedstawić użytkownikom co najmniej jeden /.auth/login/<PROVIDER> link, aby zalogować się do aplikacji przy użyciu wybranego dostawcy.

Zachowanie autoryzacji

W witrynie Azure Portal możesz edytować ustawienia uwierzytelniania aplikacji kontenera, aby skonfigurować je przy użyciu różnych zachowań, gdy żądanie przychodzące nie jest uwierzytelnione. W poniższych nagłówkach opisano opcje.

• Zezwalaj na nieuwierzytelniony dostęp: Ta opcja pozostawia autoryzację nieuwierzytelnionego ruchu kodowi aplikacji. W przypadku uwierzytelnionych żądań usługa Container Apps przekazuje również informacje uwierzytelniania w nagłówkach HTTP. Aplikacja może używać informacji zawartych w nagłówkach do podejmowania decyzji o autoryzacji dotyczących danego żądania.

  Ta opcja zapewnia większą elastyczność obsługi żądań anonimowych. Umożliwia to na przykład prezentowanie wielu dostawców logowania użytkownikom. Należy jednak napisać kod.

• Wymagaj uwierzytelniania: ta opcja odrzuca nieuwierzytelniony ruch do aplikacji. To odrzucenie może przyjąć formę działania przekierowującego do jednego ze skonfigurowanych dostawców tożsamości. W takich przypadkach klient przeglądarki jest przekierowywany do /.auth/login/<PROVIDER> wybranego dostawcy. Jeśli żądanie anonimowe pochodzi z natywnej aplikacji mobilnej, zwracana odpowiedź to HTTP 401 Unauthorized. Można również skonfigurować odrzucenie jako HTTP 401 Unauthorized lub HTTP 403 Forbidden dla wszystkich żądań.

  Dzięki tej opcji nie musisz pisać żadnego kodu uwierzytelniania w aplikacji. Bardziej precyzyjna autoryzacja, taka jak autoryzacja specyficzna dla roli, może być obsługiwana przez sprawdzenie oświadczeń użytkownika (zobacz Uzyskiwanie dostępu do oświadczeń użytkowników).

  Uwaga

  Ograniczenie dostępu do aplikacji ma zastosowanie do wszystkich żądań do aplikacji. Te ograniczenia mogą nie być preferowane w przypadku aplikacji z publicznie dostępną stroną internetową, co jest typowe w wielu aplikacjach jednostronicowych.

  Uwaga

  Domyślnie każdy użytkownik w dzierżawie Microsoft Entra może zażądać tokenu dla Twojej aplikacji z usługi Microsoft Entra ID. Aplikację można skonfigurować w identyfikatorze Entra firmy Microsoft, jeśli chcesz ograniczyć dostęp do aplikacji do zdefiniowanego zestawu użytkowników.

Dostosowywanie logowania i wylogowywanie

Uwierzytelnianie w usłudze Container Apps zapewnia wbudowane punkty końcowe do logowania się i wylogowywania. Po włączeniu tej funkcji te punkty końcowe są dostępne pod prefiksem trasy /.auth w aplikacji kontenerowej.

Korzystanie z wielu dostawców logowania

Konfiguracja portalu nie oferuje gotowego sposobu na udostępnienie użytkownikom wielu dostawców logowania (na przykład Facebooka i X). Jednak dodanie funkcji do aplikacji nie jest trudne. Opisane są następujące kroki:

Najpierw na stronie Uwierzytelnianie/autoryzacja w witrynie Azure Portal skonfiguruj każdego dostawcę tożsamości, który chcesz włączyć.

W obszarze Akcja do wykonania, gdy żądanie nie jest uwierzytelnione, wybierz pozycję Zezwalaj na żądania anonimowe (bez akcji).

Na stronie logowania lub na pasku nawigacyjnym lub w dowolnej innej lokalizacji aplikacji dodaj link logowania do każdego z włączonych dostawców (/.auth/login/<provider>). Na przykład:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>

Gdy użytkownik wybierze jeden z linków, interfejs użytkownika dla odpowiednich dostawców zostanie wyświetlony użytkownikowi.

Aby przekierować użytkownika po zalogowaniu do niestandardowego adresu URL, użyj parametru ciągu zapytania post_login_redirect_uri (nie mylić z adresem URI przekierowania w konfiguracji dostawcy tożsamości). Aby na przykład po zalogowaniu przekierować użytkownika do /Home/Index, użyj następującego kodu HTML:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Logowanie kierowane przez klienta

W przypadku logowania kierowanego przez klienta aplikacja loguje użytkownika do dostawcy tożsamości przy użyciu zestawu SDK specyficznego dla dostawcy. Następnie kod aplikacji przesyła wynikowy token uwierzytelniania do usługi Container Apps w celu weryfikacji (zobacz Przepływ uwierzytelniania) przy użyciu żądania HTTP POST.

Aby zweryfikować token dostawcy, należy najpierw skonfigurować aplikację kontenera przy użyciu żądanego dostawcy. W czasie działania, po pobraniu tokenu uwierzytelniania od dostawcy, wyślij token do /.auth/login/<provider> w celu weryfikacji. Na przykład:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Format tokenu różni się nieco w zależności od dostawcy. Aby uzyskać szczegółowe informacje, zobacz następującą tabelę:

Jeśli token dostawcy zostanie pomyślnie zweryfikowany, interfejs API zwróci w treści odpowiedzi authenticationToken, czyli token sesji.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Po utworzeniu tokenu sesji możesz uzyskać dostęp do chronionych zasobów aplikacji, dodając X-ZUMO-AUTH nagłówek do żądań HTTP. Na przykład:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Wyloguj się z sesji

Użytkownicy mogą się wylogować, wysyłając GET żądanie do punktu końcowego /.auth/logout aplikacji. Żądanie GET wykonuje następujące działania:

• Czyści pliki cookie uwierzytelniania z bieżącej sesji.
• Usuwa tokeny bieżącego użytkownika z magazynu tokenów.
• Powoduje wylogowanie po stronie serwera u dostawcy tożsamości dla Microsoft Entra ID i Google.

Oto prosty link wylogowania na stronie internetowej:

<a href="/.auth/logout">Sign out</a>

Domyślnie pomyślne wylogowanie przekierowuje klienta do adresu URL /.auth/logout/done. Możesz zmienić stronę przekierowania po wylogowaniu, dodając post_logout_redirect_uri parametr zapytania. Na przykład:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Pamiętaj, aby zakodować wartość post_logout_redirect_uri.

Adres URL musi być hostowany w tej samej domenie, jeśli używasz w pełni kwalifikowanych adresów URL.

Uzyskiwanie dostępu do oświadczeń użytkowników w kodzie aplikacji

W przypadku wszystkich frameworków językowych usługa Container Apps udostępnia kodowi aplikacji roszczenia zawarte w tokenie przychodzącym. Oświadczenia są wstrzykiwane do nagłówków żądania, które są obecne niezależnie od tego, czy pochodzą od uwierzytelnionego użytkownika końcowego, czy od aplikacji klienckiej. Żądania zewnętrzne nie mogą ustawiać tych nagłówków, dlatego są obecne tylko wtedy, gdy są ustawione przez usługę Container Apps. Oto przykładowe nagłówki:

• X-MS-CLIENT-PRINCIPAL-NAME
• X-MS-CLIENT-PRINCIPAL-ID

Kod napisany w dowolnym języku lub strukturze może uzyskać informacje potrzebne z tych nagłówków.

Oprócz tych nagłówków tożsamości aplikacja może uzyskać dostęp do tokenów uwierzytelniania (takich jak tokeny dostępu Microsoft Entra) za pośrednictwem nagłówków żądań takich jak X-MS-TOKEN-AAD-ACCESS-TOKEN. Aby udostępnić te tokeny, należy włączyć magazyn tokenów w ramach ustawień uwierzytelniania aplikacji kontenera. Po włączeniu żądania wysyłane do aplikacji zawierają dodatkowe nagłówki związane z tokenem, w zależności od skonfigurowanego dostawcy tożsamości i przepływu uwierzytelniania.

Zabezpieczanie punktów końcowych za pomocą usługi EasyAuth

Podczas zabezpieczania punktów końcowych przy użyciu uwierzytelniania usługi Azure Container Apps należy zarejestrować aplikację przy użyciu identyfikatora Entra firmy Microsoft i skonfigurować ustawienia uwierzytelniania.

Wykonaj następujące kroki, aby skonfigurować bezpieczny dostęp:

1. Utwórz rejestrację aplikacji usługi Azure AD

   az ad app create \
     --display-name <APP_DISPLAY_NAME> \
     --sign-in-audience AzureADMyOrg
   ---
   
   

2. Włącz aplikację, aby umożliwić wydawanie tokenów tożsamości. Ten krok jest wymagany do obsługi usługi Easy Auth.

   az ad app update \
     --id <APPLICATION_ID> \
     --enable-id-token-issuance true
   

3. Dodaj URI przekierowania dla callbacku Easy Auth.

   az ad app update \
     --id <APP_ID> \
     --web-redirect-uris "https://<APP-NAME>.<ENVIRONMENT-NAME>.<REGION>.azurecontainerapps.io/.auth/login/aad/callback"
   ---
   
   

4. Generowanie klucza tajnego klienta

   az ad app credential reset \
     --id <APP_ID>" \
     --display-name "<APP_NAME>-Secret"
   ---
   
   

5. Utwórz jednostkę usługi dla aplikacji.

   az ad sp create --id <APP_ID>
   ---
   
   

6. Skonfiguruj aplikację kontenera tak, aby korzystała z uwierzytelniania identyfikatora Entra firmy Microsoft.

   Upewnij się, że podana wartość symbolu zastępczego <APP_NAME> to nazwa aplikacji skonfigurowanej do pracy z usługą EasyAuth.

   az containerapp auth microsoft update \
     --name <APP_NAME> \
     --resource-group <RESOURCE_GROUP> \
     --client-id <APP_ID> \
     --client-secret <CLIENT_SECRET> \
     --tenant-id <TENANT_ID> \
     --yes
   

Następne kroki

Aby uzyskać szczegółowe informacje na temat zabezpieczania aplikacji kontenera, zapoznaj się z następującymi artykułami.

• Microsoft Entra ID
• Facebook
• GitHub
• Google
• X
• Custom OpenID Connect