Ověřování a autorizace v Azure Container Apps
Azure Container Apps poskytuje integrované funkce ověřování a autorizace (někdy označované jako Snadné ověřování), které zajišťují zabezpečení externí aplikace kontejneru s povoleným příchozím přenosem dat s minimálním nebo žádným kódem.
Podrobnosti o ověřování a autorizaci najdete v následujících příručkách pro váš výběr poskytovatele.
Proč používat integrované ověřování?
Tuto funkci nemusíte používat k ověřování a autorizaci. Ve webovém rozhraní, které si zvolíte, můžete použít sbalené funkce zabezpečení nebo můžete napsat vlastní nástroje. Implementace zabezpečeného řešení pro ověřování (přihlášení uživatelů) a autorizace (poskytování přístupu k zabezpečeným datům) ale může výrazně znamenat značné úsilí. Musíte se ujistit, že dodržujete osvědčené postupy a standardy v oboru a udržujete implementaci v aktualizovaném stavu.
Integrovaná funkce ověřování pro Container Apps šetří čas a úsilí tím, že poskytuje předem připravená ověřování s federovanými zprostředkovateli identit. Tyto funkce umožňují soustředit se na vývoj aplikace více času a méně času na sestavování systémů zabezpečení.
Nabízí například tyto výhody:
- Azure Container Apps poskytuje přístup k různým integrovaným poskytovatelům ověřování.
- Integrované funkce ověřování nevyžadují žádný konkrétní jazyk, sadu SDK, znalosti zabezpečení ani žádný kód, který musíte napsat.
- Můžete se integrovat s několika poskytovateli, včetně Microsoft Entra ID, Facebooku, Googlu a X.
Zprostředkovatelé identit
Container Apps používá federovanou identitu, ve které za vás spravuje identity a tok ověřování uživatelů třetí strany. Ve výchozím nastavení jsou k dispozici následující zprostředkovatelé identity:
| Poskytovatel | Koncový bod přihlášení | Pokyny k návodům |
|---|---|---|
| Microsoft Identity Platform | /.auth/login/aad |
Microsoft Identity Platform |
/.auth/login/facebook |
||
| GitHub | /.auth/login/github |
GitHub |
/.auth/login/google |
||
| X | /.auth/login/x |
X |
| Libovolný zprostředkovatel OpenID Connect | /.auth/login/<providerName> |
OpenID Connect |
Pokud používáte některého z těchto poskytovatelů, je koncový bod přihlášení k dispozici pro ověření uživatele a ověření ověřovacího tokenu od zprostředkovatele. Uživatelům můžete poskytnout libovolný počet těchto možností poskytovatele.
Důležité informace o používání integrovaného ověřování
Tato funkce by se měla používat jenom s HTTPS. Ujistěte se allowInsecure , že je v konfiguraci příchozího přenosu dat vaší aplikace kontejneru zakázaná.
Aplikaci kontejneru můžete nakonfigurovat pro ověřování pomocí obsahu a rozhraní API webu nebo bez omezení přístupu k obsahu a rozhraním API webu. Pokud chcete omezit přístup aplikace jenom na ověřené uživatele, nastavte jeho nastavení Omezit přístup na Vyžadovat ověřování. Pokud se chcete ověřit, ale neomezovat přístup, nastavte jeho nastavení Omezit přístup na Možnost Povolit neověřený přístup.
Ve výchozím nastavení každá aplikace kontejneru vydává vlastní jedinečný soubor cookie nebo token pro ověřování. Můžete také zadat vlastní podpisové a šifrovací klíče.
Architektura funkcí
Komponenta middlewaru pro ověřování a autorizaci je funkce platformy, která běží jako kontejner sajdkáře na každé replice ve vaší aplikaci. Pokud je tato možnost povolená, vaše aplikace zpracuje každý příchozí požadavek HTTP po průchodu vrstvou zabezpečení.
Middleware platformy zpracovává několik věcí pro vaši aplikaci:
- Ověřuje uživatele a klienty pomocí zadaných zprostředkovatelů identity.
- Spravuje ověřenou relaci.
- Vloží informace o identitě do hlaviček požadavků HTTP.
Modul ověřování a autorizace se spouští v samostatném kontejneru, který je izolovaný od kódu vaší aplikace. Vzhledem k tomu, že kontejner zabezpečení neběží v procesu, není možná přímá integrace s konkrétními jazykovými architekturami. Relevantní informace, které vaše aplikace potřebuje, se ale poskytují v hlavičce požadavků, jak je vysvětleno v tomto článku.
Tok ověřování
Tok ověřování je stejný pro všechny poskytovatele, ale liší se v závislosti na tom, jestli se chcete přihlásit pomocí sady SDK poskytovatele:
Bez sady SDK zprostředkovatele (tok řízeného serverem nebo tok serveru): Aplikace deleguje federované přihlašování do Container Apps. Delegování se obvykle používá u aplikací prohlížeče, které uživateli zobrazí přihlašovací stránku poskytovatele.
Se sadou SDK zprostředkovatele (tok řízený klientem nebo tokem klienta): Aplikace přihlásí uživatele k poskytovateli ručně a pak odešle ověřovací token do Container Apps k ověření. Tento přístup je typický pro aplikace bez prohlížeče, které uživateli nenabídnou přihlašovací stránku poskytovatele. Příkladem je nativní mobilní aplikace, která uživatele podepisuje pomocí sady SDK poskytovatele.
Volání z důvěryhodné aplikace prohlížeče v Container Apps do jiného rozhraní REST API v Container Apps je možné ověřit pomocí toku řízeného serverem. Další informace najdete v tématu Přizpůsobení přihlášení a odhlášení.
V tabulce jsou uvedené kroky toku ověřování.
| Krok | Bez sady SDK zprostředkovatele | S využitím sady SDK zprostředkovatele |
|---|---|---|
| 1. Přihlášení uživatele | Přesměruje klienta na /.auth/login/<PROVIDER>. |
Klientský kód podepíše uživatele přímo pomocí sady SDK poskytovatele a obdrží ověřovací token. Informace najdete v dokumentaci poskytovatele. |
| 2. Po ověření | Zprostředkovatel přesměruje klienta na /.auth/login/<PROVIDER>/callback. |
Klientský kód publikuje token od zprostředkovatele k /.auth/login/<PROVIDER> ověření. |
| 3. Navázání ověřené relace | Container Apps přidá do odpovědi ověřený soubor cookie. | Container Apps vrátí do kódu klienta vlastní ověřovací token. |
| 4. Obsluha ověřeného obsahu | Klient zahrnuje ověřovací soubor cookie v následných požadavcích (automaticky zpracovávaný prohlížečem). | Kód klienta představuje ověřovací token v X-ZUMO-AUTH hlavičce. |
V klientských prohlížečích může Container Apps automaticky směrovat všechny neověřené uživatele na /.auth/login/<PROVIDER>. Můžete také prezentovat uživatele s jedním nebo více /.auth/login/<PROVIDER> odkazy pro přihlášení k vaší aplikaci pomocí jejich zvoleného poskytovatele.
Chování autorizace
Na webu Azure Portal můžete upravit nastavení ověřování aplikace kontejneru a nakonfigurovat ho s různými chováními v případě, že příchozí požadavek není ověřený. Následující nadpisy popisují možnosti.
Povolit neověřený přístup: Tato možnost znemožní autorizaci neověřeného provozu do kódu aplikace. U ověřených požadavků služba Container Apps předává také ověřovací informace v hlavičce HTTP. Aplikace může k rozhodování o autorizaci žádosti použít informace v hlavičce.
Tato možnost poskytuje větší flexibilitu při zpracování anonymních požadavků. Umožňuje například uživatelům prezentovat více poskytovatelů přihlašování. Musíte ale napsat kód.
Vyžadovat ověření: Tato možnost odmítne veškerý neověřený provoz do vaší aplikace. Toto odmítnutí může být akce přesměrování na jednoho z nakonfigurovaných zprostředkovatelů identity. V těchto případech se klient prohlížeče přesměruje na
/.auth/login/<PROVIDER>zprostředkovatele, který zvolíte. Pokud anonymní požadavek pochází z nativní mobilní aplikace, vrácená odpověď je .HTTP 401 UnauthorizedZamítnutí můžete také nakonfigurovat tak, aby bylo neboHTTP 401 UnauthorizedHTTP 403 Forbiddenpro všechny požadavky.Pomocí této možnosti nemusíte v aplikaci psát žádný ověřovací kód. Podrobná autorizace, jako je autorizace specifická pro roli, se dá zpracovat kontrolou deklarací identity uživatele (viz Deklarace identity uživatelů v Accessu).
Upozornění
Omezení přístupu tímto způsobem platí pro všechna volání vaší aplikace, která nemusí být žádoucí pro aplikace, které chtějí veřejně dostupnou domovskou stránku, stejně jako v mnoha jednostrákových aplikacích.
Poznámka:
Ve výchozím nastavení může každý uživatel ve vašem tenantovi Microsoft Entra požádat o token pro vaši aplikaci z ID Microsoft Entra. Aplikaci můžete nakonfigurovat v Microsoft Entra ID, pokud chcete omezit přístup k aplikaci na definovanou sadu uživatelů.
Přizpůsobení přihlášení a odhlášení
Ověřování Container Apps poskytuje integrované koncové body pro přihlášení a odhlášení. Pokud je tato funkce povolená, jsou tyto koncové body dostupné pod předponou /.auth trasy ve vaší aplikaci kontejneru.
Použití více poskytovatelů přihlašování
Konfigurace portálu nenabízí způsob, jak uživatelům prezentovat více poskytovatelů přihlašování (například Facebook i X). Není ale obtížné do aplikace přidat funkce. Postup je uveden níže:
Nejprve na stránce Ověřování nebo autorizace na webu Azure Portal nakonfigurujte každého zprostředkovatele identity, kterého chcete povolit.
V akci, která se má provést, když požadavek není ověřený, vyberte Povolit anonymní žádosti (bez akce).
Na přihlašovací stránce nebo na navigačním panelu nebo v jiném umístění vaší aplikace přidejte odkaz pro přihlášení ke každému poskytovateli, který jste povolili (/.auth/login/<provider>). Příklad:
<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>
Když uživatel vybere některý z odkazů, uživatelské rozhraní pro příslušné zprostředkovatele se uživateli zobrazí.
Pokud chcete uživatele po přihlášení přesměrovat na vlastní adresu URL, použijte post_login_redirect_uri parametr řetězce dotazu (nezaměňte s identifikátorem URI přesměrování v konfiguraci zprostředkovatele identity). Pokud chcete například přejít uživatele po /Home/Index přihlášení, použijte následující kód HTML:
<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>
Přihlášení řízené klientem
V přihlášení řízeném klientem se aplikace přihlásí uživatele k zprostředkovateli identity pomocí sady SDK specifické pro zprostředkovatele. Kód aplikace pak odešle výsledný ověřovací token do Container Apps k ověření (viz ověřovací tok) pomocí požadavku HTTP POST.
Pokud chcete ověřit token zprostředkovatele, musí být aplikace kontejneru nejprve nakonfigurovaná s požadovaným poskytovatelem. Za běhu po načtení ověřovacího tokenu od zprostředkovatele zastavte token k /.auth/login/<provider> ověření. Příklad:
POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json
{"id_token":"<token>","access_token":"<token>"}
Formát tokenu se mírně liší podle poskytovatele. Podrobnosti najdete v následující tabulce:
| Hodnota zprostředkovatele | Požadováno v textu požadavku | Komentáře |
|---|---|---|
aad |
{"access_token":"<ACCESS_TOKEN>"} |
Vlastnosti id_tokena expires_in , refresh_tokenjsou volitelné. |
microsoftaccount |
{"access_token":"<ACCESS_TOKEN>"} nebo {"authentication_token": "<TOKEN>" |
authentication_token je upřednostňovaná před access_token. Vlastnost expires_in je nepovinná. Při vyžádání tokenu ze služeb Live vždy požádejte o wl.basic obor. |
google |
{"id_token":"<ID_TOKEN>"} |
Vlastnost authorization_code je nepovinná. authorization_code Poskytnutí hodnoty přidá přístupový token a obnovovací token do úložiště tokenů. Při zadání authorization_code lze také volitelně připojit redirect_uri k vlastnosti. |
facebook |
{"access_token":"<USER_ACCESS_TOKEN>"} |
Použijte platný přístupový token uživatele z Facebooku. |
twitter |
{"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"} |
|
Pokud se token zprostředkovatele úspěšně ověří, rozhraní API se vrátí s textem authenticationToken odpovědi, což je váš token relace.
{
"authenticationToken": "...",
"user": {
"userId": "sid:..."
}
}
Jakmile budete mít tento token relace, budete mít přístup k chráněným prostředkům aplikace tak, že do požadavků HTTP přidáte hlavičku X-ZUMO-AUTH . Příklad:
GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>
Odhlášení z relace
Uživatelé se můžou odhlásit odesláním GET požadavku do koncového /.auth/logout bodu aplikace. Žádost GET provádí následující akce:
- Vymaže ověřovací soubory cookie z aktuální relace.
- Odstraní tokeny aktuálního uživatele z úložiště tokenů.
- Provede odhlášení na straně serveru u zprostředkovatele identity pro Microsoft Entra ID a Google.
Tady je jednoduchý odkaz pro odhlášení na webové stránce:
<a href="/.auth/logout">Sign out</a>
Ve výchozím nastavení úspěšné odhlášení přesměruje klienta na adresu URL /.auth/logout/done. Stránku přesměrování po odhlášení můžete změnit přidáním parametru post_logout_redirect_uri dotazu. Příklad:
GET /.auth/logout?post_logout_redirect_uri=/index.html
Nezapomeňte zakódovat hodnotu post_logout_redirect_uri.
Adresa URL musí být hostovaná ve stejné doméně při použití plně kvalifikovaných adres URL.
Přístup k deklaracím identity uživatelů v kódu aplikace
Pro všechna jazyková rozhraní služba Container Apps zpřístupní deklarace identity v příchozím tokenu kódu vaší aplikace. Deklarace identity se vloží do hlaviček požadavků, které se nacházejí bez ohledu na to, jestli pochází od ověřeného koncového uživatele nebo klientské aplikace. Externí požadavky nesmí tyto hlavičky nastavit, takže jsou k dispozici jenom v případě, že je nastaví Container Apps. Mezi příklady hlaviček patří:
X-MS-CLIENT-PRINCIPAL-NAMEX-MS-CLIENT-PRINCIPAL-ID
Kód napsaný v libovolném jazyce nebo rozhraní může získat informace, které potřebuje, z těchto hlaviček.
Poznámka:
Různá jazyková rozhraní mohou tyto hlavičky prezentovat kódu aplikace v různých formátech, jako jsou malá písmena nebo velká písmena názvu.
Další kroky
Podrobnosti o zabezpečení kontejnerové aplikace najdete v následujících článcích.