Ověřování a autorizace ve službě Aplikace Azure a Azure Functions

Článek
10/18/2023

služba Aplikace Azure poskytuje integrované možnosti ověřování a autorizace (někdy označované jako Snadné ověřování), takže se můžete přihlásit k uživatelům a datům přístupu tak, že do webové aplikace, rozhraní RESTful API a mobilního back-endu napíšete minimální nebo žádný kód.Azure Functions. Tento článek popisuje, jak app Service pomáhá zjednodušit ověřování a autorizaci pro vaši aplikaci.

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. Budete ale muset zajistit, aby vaše řešení zůstalo aktuální s nejnovějšími aktualizacemi zabezpečení, protokolu a prohlížeče.

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) 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 App Service a Azure Functions vám může ušetřit čas a úsilí tím, že poskytuje předem připravená ověřování s federovanými zprostředkovateli identit, což vám umožní soustředit se na zbytek vaší aplikace.

služba Aplikace Azure umožňuje integrovat do webové aplikace nebo rozhraní API celou řadu možností ověřování, aniž byste je implementovali sami.
Je integrovaná přímo do platformy a nevyžaduje žádný konkrétní jazyk, sadu SDK, znalosti zabezpečení ani žádný kód, který by bylo možné využít.
Můžete se integrovat s několika zprostředkovateli přihlášení. Například Microsoft Entra, Facebook, Google, Twitter.

Vaše aplikace může potřebovat podporovat složitější scénáře, jako je integrace sady Visual Studio nebo přírůstkový souhlas. Pro podporu těchto scénářů je k dispozici několik různých řešení ověřování. Další informace najdete ve scénářích identit.

Zprostředkovatelé identit

App Service používá federovanou identitu, ve které za vás spravuje identity uživatelů a tok ověřování 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`	Přihlášení ke službě App Service Microsoft Identity Platform
Facebook	`/.auth/login/facebook`	Přihlášení k Facebooku ve službě App Service
Google	`/.auth/login/google`	Přihlášení Ke službě App Service Google
Twitter	`/.auth/login/twitter`	Přihlášení k Twitteru ve službě App Service
GitHub	`/.auth/login/github`	Přihlášení ke službě App Service na GitHubu
Přihlášení pomocí Apple	`/.auth/login/apple`	Přihlášení ke službě App Service pomocí přihlášení Apple (Preview)
Libovolný zprostředkovatel OpenID Připojení	`/.auth/login/<providerName>`	Přihlášení k OpenID služby App Service Připojení

Když tuto funkci nakonfigurujete u některého z těchto poskytovatelů, bude jeho přihlašovací koncový bod dostupný pro ověřování uživatelů a ověření ověřovacích tokenů od zprostředkovatele. Uživatelům můžete poskytnout libovolný počet těchto možností přihlášení.

Důležité informace o používání integrovaného ověřování

Povolení této funkce způsobí automatické přesměrování všech požadavků na vaši aplikaci na HTTPS bez ohledu na nastavení konfigurace služby App Service k vynucení HTTPS. Toto nastavení můžete zakázat pomocí requireHttps nastavení v konfiguraci V2. Doporučujeme ale držet se protokolu HTTPS a měli byste zajistit, aby se žádné tokeny zabezpečení nepřesílaly přes nezabezpečené připojení HTTP.

App Service se dá použít k ověřování s obsahem webu a rozhraními API nebo bez omezení přístupu k obsahu webu a rozhraním API. Omezení přístupu je možné nastavit v části Nastavení ověřování ověřování>vaší webové aplikace. Pokud chcete omezit přístup aplikace jenom k ověřeným uživatelům, nastavte akci, která se má provést, když se požadavek neověří pro přihlášení pomocí některého z nakonfigurovaných zprostředkovatelů identity. Pokud chcete provést ověření, ale neomezíte přístup, nastavte akci, která se provede, když se požadavek neověří na Povolit anonymní žádosti (bez akce).

Důležité

Každé registraci aplikace byste měli udělit vlastní oprávnění a souhlas. Vyhněte se sdílení oprávnění mezi prostředími pomocí samostatných registrací aplikací pro samostatné sloty nasazení. Při testování nového kódu může tento postup pomoct zabránit problémům, které mají vliv na produkční aplikaci.

Jak to funguje

Protokolování a trasování

Architektura funkcí

Komponenta middlewaru pro ověřování a autorizaci je funkce platformy, která běží na stejném virtuálním počítači jako vaše aplikace. Když je povolená, každý příchozí požadavek HTTP ho před zpracováním vaší aplikace projde.

Middleware platformy zpracovává několik věcí pro vaši aplikaci:

Ověřuje uživatele a klienty pomocí zadaných zprostředkovatelů identity.
Ověřuje, ukládá a aktualizuje tokeny OAuth vydané nakonfigurovanými zprostředkovateli identit.
Spravuje ověřenou relaci.
Vloží informace o identitě do hlaviček požadavků HTTP.

Modul běží odděleně od kódu aplikace a dá se nakonfigurovat pomocí nastavení Azure Resource Manageru nebo pomocí konfiguračního souboru. Nejsou vyžadovány žádné sady SDK, konkrétní programovací jazyky ani změny kódu aplikace.

Architektura funkcí ve Windows (nasazení bez kontejneru)

Modul ověřování a autorizace běží jako nativní modul IIS ve stejném sandboxu jako vaše aplikace. Když je povolená, každý příchozí požadavek HTTP ho před zpracováním vaší aplikace projde.

Architektura funkcí v Linuxu a kontejnerech

Modul ověřování a autorizace se spouští v samostatném kontejneru, který je izolovaný od kódu vaší aplikace. Pomocí vzoru ambasadora komunikuje s příchozím provozem, aby prováděl podobné funkce jako ve Windows. Vzhledem k tomu, že 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 předávají pomocí hlaviček požadavků, jak je vysvětleno níže.

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: Aplikace deleguje federované přihlašování do služby App Service. Obvykle se jedná o případ s aplikacemi prohlížeče, které můžou uživateli prezentovat přihlašovací stránku poskytovatele. Kód serveru spravuje proces přihlášení, takže se také označuje jako tok řízený serverem nebo tok serveru. Tento případ platí pro aplikace prohlížeče a mobilní aplikace, které k ověřování používají vložený prohlížeč.
Sada SDK zprostředkovatele: Aplikace přihlásí uživatele k poskytovateli ručně a pak odešle ověřovací token do služby App Service k ověření. Obvykle se jedná o aplikace bez prohlížeče, které nemůžou uživateli prezentovat přihlašovací stránku poskytovatele. Kód aplikace spravuje proces přihlašování, takže se také označuje jako tok řízený klientem nebo tok klienta. Tento případ platí pro rozhraní REST API, Azure Functions a klienty prohlížeče JavaScriptu a také aplikace prohlížeče, které potřebují větší flexibilitu v procesu přihlašování. Platí také pro nativní mobilní aplikace, které přihlašují uživatele pomocí sady SDK poskytovatele.

Volání z důvěryhodné aplikace prohlížeče ve službě App Service do jiného rozhraní REST API ve službě App Service nebo Azure Functions 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í.

Následující tabulka ukazuje 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	Služba App Service přidá do odpovědi ověřený soubor cookie.	App Service 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 App Service 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

Důležité

Ve výchozím nastavení tato funkce poskytuje pouze ověřování, nikoli autorizaci. Kromě kontrol, které tady nakonfigurujete, může vaše aplikace i nadále muset provést rozhodnutí o autorizaci.

Na webu Azure Portal můžete nakonfigurovat službu App Service s řadou chování, když se příchozí požadavek neověří. Následující nadpisy popisují možnosti.

Přístup k restrice

Povolte neověřené požadavky . Tato možnost odblokuje autorizaci neověřeného provozu do kódu aplikace. U ověřených požadavků služba App Service předává také ověřovací informace v hlavičce HTTP.

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. Konkrétní akce, která se má provést, se zadává v části Neověřené žádosti .

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:

Při použití zprostředkovatele identity Microsoftu pro uživatele ve vaší organizaci je výchozím chováním, že každý uživatel ve vašem tenantovi Microsoft Entra může požádat o token pro vaši aplikaci. Aplikaci v Microsoft Entra můžete nakonfigurovat, pokud chcete omezit přístup k aplikaci na definovanou sadu uživatelů. App Service také nabízí některé základní integrované kontroly autorizace, které mohou pomoct s některými ověřeními. Další informace o autorizaci v Microsoft Entra najdete v tématu Základy autorizace Microsoft Entra.

Neověřené požadavky

Http 302 Nalezeno přesměrování: Doporučeno pro akci Přesměrování webů 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.
HTTP 401 Neautorizováno: Doporučuje se pro rozhraní API , pokud anonymní požadavek pochází z nativní mobilní aplikace, vrácená odpověď je HTTP 401 Unauthorized. Zamítnutí můžete také nakonfigurovat tak, aby bylo pro všechny požadavky.HTTP 401 Unauthorized
HTTP 403 Zakázáno Konfiguruje zamítnutí jako pro HTTP 403 Forbidden všechny požadavky.
Http 404 Nenalezena konfigurace zamítnutí pro HTTP 404 Not found všechny požadavky.

Úložiště tokenů

App Service poskytuje integrované úložiště tokenů, což je úložiště tokenů přidružených uživatelům webových aplikací, rozhraní API nebo nativních mobilních aplikací. Když povolíte ověřování u libovolného zprostředkovatele, bude toto úložiště tokenů pro vaši aplikaci okamžitě dostupné. Pokud kód aplikace potřebuje přístup k datům od těchto poskytovatelů jménem uživatele, například:

post to the authenticated user's Facebook timeline
čtení podnikových dat uživatele pomocí rozhraní Microsoft Graph API

Obvykle musíte napsat kód pro shromažďování, ukládání a aktualizaci těchto tokenů ve vaší aplikaci. V úložišti tokenů stačí načíst tokeny , když je potřebujete, a dát službě App Service vědět, aby je aktualizoval, když se stanou neplatnými.

Tokeny ID, přístupové tokeny a obnovovací tokeny se ukládají do mezipaměti pro ověřenou relaci a jsou přístupné jenom přidruženým uživatelem.

Pokud v aplikaci nepotřebujete pracovat s tokeny, můžete zakázat úložiště tokenů na stránce Ověřování a autorizace vaší aplikace.

Protokolování a trasování

Pokud povolíte protokolování aplikace, uvidíte trasování ověřování a autorizace přímo v souborech protokolů. Pokud se zobrazí chyba ověřování, kterou jste nečekali, můžete snadno najít všechny podrobnosti v existujících protokolech aplikace. Pokud povolíte trasování neúspěšných požadavků, můžete přesně zjistit, jakou roli mohl modul ověřování a autorizace hrát v neúspěšném požadavku. V protokolech trasování vyhledejte odkazy na modul s názvem EasyAuthModule_32/64.

Důležité informace o používání služby Azure Front Door

Při použití služby Aplikace Azure service se snadným ověřováním za Azure Front Doorem nebo jinými reverzními proxy servery je potřeba vzít v úvahu několik dalších věcí.

Zakázání Ukládání do mezipaměti pro pracovní postup ověřování

Další informace o tom, jak nakonfigurovat pravidla ve službě Azure Front Door pro zákaz ukládání do mezipaměti pro ověřování a autorizační stránky, najdete v tématu Zakázání mezipaměti pro pracovní postup ověřování a ověřování.
Použití koncového bodu služby Front Door pro přesměrování

Služba App Service není obvykle přístupná přímo při zveřejnění přes Azure Front Door. To se dá zabránit například zveřejněním služby App Service prostřednictvím služby Private Link ve službě Azure Front Door Premium. Aby se zabránilo pracovnímu postupu ověřování přesměrování provozu zpět do služby App Service, je důležité nakonfigurovat aplikaci tak, aby se přesměrovává zpět na https://<front-door-endpoint>/.auth/login/<provider>/callback.
Ujistěte se, že služba App Service používá správný identifikátor URI přesměrování.

V některých konfiguracích služba App Service používá jako identifikátor URI přesměrování místo plně kvalifikovaného názvu domény služby Front Door plně kvalifikovaný název domény služby App Service. To povede k problému, kdy se klient přesměruje do služby App Service místo služby Front Door. Pokud to chcete změnit, musí být nastavení nastavené tak, forwardProxy aby Standard služba App Service respektovala hlavičku nastavenou X-Forwarded-Host službou Azure Front Door.

Jiné reverzní proxy servery, jako je Aplikace Azure Gateway nebo produkty třetích stran, můžou používat jiné hlavičky a potřebují jiné nastavení forwardProxy.

Tuto konfiguraci není možné provést prostřednictvím webu Azure Portal ještě dnes a je potřeba ji provést prostřednictvím az rest:

Export nastavení

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

Aktualizace nastavení

Vyhledat
```
"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}
```
a ujistěte se, že je nastavená tak, convention aby Standard respektovala hlavičku X-Forwarded-Host používanou službou Azure Front Door.

Nastavení importu

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Další materiály

Ukázky: