Udostępnij za pośrednictwem

Uwierzytelnianie i autoryzacja w usłudze Azure Container Apps

  • Artykuł

Usługa Azure Container Apps udostępnia wbudowane funkcje uwierzytelniania i autoryzacji (czasami określane jako "Easy Auth"), aby zabezpieczyć zewnętrzną aplikację kontenera z obsługą ruchu przychodzącego z minimalnym kodem lub bez kodu.

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

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 której dostawca tożsamości innej firmy zarządza tożsamościami użytkowników i przepływem uwierzytelniania. Domyślnie są dostępni następujący dostawcy tożsamości:

Dostawca Punkt końcowy logowania Wskazówki dotyczące instrukcji
Platforma tożsamości Microsoft /.auth/login/aad Platforma tożsamości Microsoft
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
X /.auth/login/x X
Dowolny dostawca openID Connect /.auth/login/<providerName> OpenID Connect

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 allowInsecure konfiguracja ruchu przychodzącego aplikacji kontenera jest wyłączona.

Aplikację kontenera można skonfigurować do uwierzytelniania przy użyciu interfejsu API lub bez ograniczania dostępu do zawartości witryny i interfejsów API. 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 oprogramowania pośredniczącego uwierzytelniania i autoryzacji jest funkcją platformy, która działa jako kontener przyczepki dla każdej repliki w aplikacji. Po włączeniu aplikacja obsługuje każde przychodzące żądanie HTTP po przejściu przez warstwę zabezpieczeń.

Diagram architektury przedstawiający żądania przechwycone przez kontener przyczepki, który współdziała z dostawcami tożsamości przed zezwoleniem na ruch do kontenera aplikacji

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 zestawu SDK dostawcy (przepływ kierowany przez serwer lub przepływ serwera): aplikacja deleguje federacyjne logowanie do usługi Container Apps. Delegowanie to zazwyczaj przypadek aplikacji przeglądarki, który przedstawia użytkownikowi stronę logowania dostawcy.

  • W przypadku zestawu SDK dostawcy (przepływu kierowanego przez klienta lub przepływu klienta): aplikacja loguje użytkowników do dostawcy ręcznie, a następnie przesyła token uwierzytelniania do usługi Container Apps w celu weryfikacji. 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ądarki w usłudze Container Apps do innego interfejsu API REST w usłudze Container Apps można uwierzytelniać przy użyciu przepływu kierowanego przez serwer. Aby uzyskać więcej informacji, zobacz Dostosowywanie logowania i wylogowywanie.

W tabeli przedstawiono kroki przepływu uwierzytelniania.

Krok Bez zestawu SDK dostawcy Zestaw SDK dostawcy
1. Logowanie użytkownika Przekierowuje klienta do /.auth/login/<PROVIDER>. Kod klienta loguje użytkownika bezpośrednio za pomocą zestawu SDK dostawcy i otrzymuje token uwierzytelniania. Aby uzyskać informacje, zobacz dokumentację dostawcy.
2. Po uwierzytelnianiu Dostawca przekierowuje klienta do /.auth/login/<PROVIDER>/callback. Kod klienta publikuje token od dostawcy do /.auth/login/<PROVIDER> w celu weryfikacji.
3. Ustanawianie sesji uwierzytelnionej Usługa Container Apps dodaje uwierzytelniony plik cookie do odpowiedzi. Usługa Container Apps zwraca własny token uwierzytelniania do kodu klienta.
4. Obsługa uwierzytelnionej zawartości Klient zawiera plik cookie uwierzytelniania w kolejnych żądaniach (automatycznie obsługiwane przez przeglądarkę). Kod klienta przedstawia token uwierzytelniania w X-ZUMO-AUTH nagłówku.

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 odcina autoryzację nieuwierzytelnionego ruchu do kodu aplikacji. W przypadku uwierzytelnionych żądań usługa Container Apps przekazuje również informacje uwierzytelniania w nagłówkach HTTP. Aplikacja może używać informacji w nagłówkach do podejmowania decyzji dotyczących autoryzacji dla żą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 być akcją przekierowania 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 lub HTTP 401 Unauthorized 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 w ten sposób ma zastosowanie do wszystkich wywołań aplikacji, które mogą nie być pożądane w przypadku aplikacji, które chcą publicznie dostępnej strony głównej, jak w wielu aplikacjach jednostronicowych.

    Uwaga

    Domyślnie każdy użytkownik w dzierżawie firmy Microsoft Entra może zażądać tokenu dla aplikacji z identyfikatora Entra firmy Microsoft. 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 usługi Container Apps zapewnia wbudowane punkty końcowe do logowania i wylogowywanie. Po włączeniu tej funkcji te punkty końcowe są dostępne w prefiksie /.auth trasy w aplikacji kontenera.

Korzystanie z wielu dostawców logowania

Konfiguracja portalu nie oferuje kluczowego sposobu prezentowania wielu dostawców logowania użytkownikom (takich jak Facebook 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 się do niestandardowego adresu URL, użyj parametru post_login_redirect_uri ciągu zapytania (nie należy mylić z identyfikatorem URI przekierowania w konfiguracji dostawcy tożsamości). Aby na przykład przejść do /Home/Index użytkownika po zalogowaniu, 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 wykonywania po pobraniu tokenu uwierzytelniania od dostawcy opublikuj token na /.auth/login/<provider> potrzeby 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ę:

Wartość dostawcy Wymagane w treści żądania Komentarze
aad {"access_token":"<ACCESS_TOKEN>"} Właściwości id_token, refresh_tokeni expires_in są opcjonalne.
microsoftaccount {"access_token":"<ACCESS_TOKEN>"} lub {"authentication_token": "<TOKEN>" authentication_token wartość jest preferowana przez access_tokenwartość . Właściwość jest opcjonalna expires_in .
Podczas żądania tokenu z usług na żywo zawsze żądaj wl.basic zakresu.
google {"id_token":"<ID_TOKEN>"} Właściwość jest opcjonalna authorization_code . authorization_code Podanie wartości powoduje dodanie tokenu dostępu i tokenu odświeżania do magazynu tokenów. Po określeniu authorization_code redirect_uri można również opcjonalnie dołączyć właściwość .
facebook {"access_token":"<USER_ACCESS_TOKEN>"} Użyj prawidłowego tokenu dostępu użytkownika z serwisu Facebook.
twitter {"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}

Jeśli token dostawcy zostanie pomyślnie zweryfikowany, interfejs API zwróci element w authenticationToken treści odpowiedzi, 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.
  • Wykonuje wylogowanie po stronie serwera na 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 struktur językowych usługa Container Apps udostępnia oświadczenia w tokenie przychodzącym kodowi aplikacji. Oświadczenia są wstrzykiwane do nagłówków żądań, które są obecne niezależnie od tego, czy od uwierzytelnionego użytkownika końcowego, czy 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.

Uwaga

Różne struktury językowe mogą przedstawiać te nagłówki do kodu aplikacji w różnych formatach, takich jak małe litery lub wielkość tytułu.

Następne kroki

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