Ověřování a autorizace v Azure App Service a Azure Functions
Azure App Service poskytuje integrované možnosti ověřování a autorizace (někdy označované jako "Snadné ověřování"), abyste mohli přihlašovat uživatele a přistupovat k datům tak, že do webové aplikace, rozhraní RESTful API, mobilního back-endu a také Azure Functions napíšete minimální kód nebo žádný kód. Tento článek popisuje, jak App Service 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é architektuře podle svého výběru můžete použít funkce zabezpečení, které jsou součástí sady, nebo si můžete napsat vlastní nástroje. Budete ale muset zajistit, aby vaše řešení bylo aktuální díky nejnovějším aktualizacím zabezpečení, protokolu a prohlížeče.
Implementace zabezpečeného řešení pro ověřování (přihlašování uživatelů) a autorizaci (poskytování přístupu k zabezpečeným datům) může vyžadovat značné úsilí. Musíte se ujistit, že dodržujete osvědčené oborové postupy a standardy 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 integrované ověřování s federovanými zprostředkovateli identit, což vám umožní soustředit se na zbytek vaší aplikace.
- Azure App Service umožňuje integrovat různé možnosti ověřování do webové aplikace nebo rozhraní API, 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 integrovat s několika poskytovateli přihlášení. Například Azure AD, Facebook, Google, Twitter.
Vaše aplikace může potřebovat podporu složitějších scénářů, jako je integrace sady Visual Studio nebo přírůstkové vyjádření souhlasu. Pro podporu těchto scénářů je k dispozici několik různých řešení ověřování. Další informace najdete v tématu Scénáře identit.
Zprostředkovatelé identit
App Service používá federovanou identitu, ve které za vás identity uživatelů a tok ověřování spravuje zprostředkovatel identity 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 How-To |
---|---|---|
Microsoft Identity Platform | /.auth/login/aad |
App Service přihlášení k platformě Microsoft Identity Platform |
/.auth/login/facebook |
App Service přihlášení k Facebooku | |
/.auth/login/google |
přihlášení App Service Google | |
/.auth/login/twitter |
App Service přihlášení k Twitteru | |
GitHub | /.auth/login/github |
App Service přihlášení ke GitHubu |
Přihlášení pomocí Apple | /.auth/login/apple |
App Service Přihlášení pomocí přihlášení Apple (Preview) |
Libovolný poskytovatel OpenID Connect | /.auth/login/<providerName> |
přihlášení App Service OpenID Connect |
Když nakonfigurujete tuto funkci s jedním z těchto zprostředkovatelů, bude její koncový bod přihlášení k dispozici pro ověřování uživatelů a ověřování 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í, že se všechny požadavky na vaši aplikaci automaticky přesměrují na HTTPS bez ohledu na nastavení konfigurace App Service pro vynucení protokolu HTTPS. Můžete to zakázat nastavením requireHttps
v konfiguraci V2. Doporučujeme ale držet se protokolu HTTPS a měli byste zajistit, aby se přes nezabezpečené připojení HTTP nepřenesly žádné tokeny zabezpečení.
App Service můžete použít k ověřování s nebo bez omezení přístupu k obsahu a rozhraním API webu. Pokud chcete omezit přístup k aplikacím jenom na ověřené uživatele, nastavte akci, která se má provést, když se požadavek neověří , aby se přihlásil pomocí některého z nakonfigurovaných zprostředkovatelů identity. Pokud chcete ověřit přístup, ale neomezovat přístup, nastavte možnost Akce, která se má provést, když požadavek není ověřený , na hodnotu Povolit anonymní požadavky (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é by ovlivnily produkční aplikaci.
Jak to funguje
Architektura funkcí
Komponenta middlewaru ověřování a autorizace je funkcí platformy, která běží na stejném virtuálním počítači jako vaše aplikace. Když je povolená, projde jím každý příchozí požadavek HTTP, než ho zpracuje vaše aplikace.
Middleware platformy pro vaši aplikaci zpracovává několik věcí:
- 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 identity.
- 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 Manager nebo konfiguračního souboru. Nevyžadují se žá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 služby IIS ve stejném sandboxu jako vaše aplikace. Když je povolená, projde jím každý příchozí požadavek HTTP, než ho zpracuje vaše aplikace.
Architektura funkcí v Linuxu a kontejnerech
Modul ověřování a autorizace běží v samostatném kontejneru izolovaném od kódu aplikace. Pomocí toho, co se označuje jako model Ambassador, interaguje s příchozím provozem a provádí 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. Důležité 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řihlášení do App Service. To je obvykle případ prohlížečových aplikací, které můžou uživateli prezentovat přihlašovací stránku poskytovatele. Kód serveru spravuje proces přihlášení, takže se také nazývá serverový tok nebo serverový tok. Tento případ platí pro aplikace prohlížeče a mobilní aplikace, které k ověřování používají vložený prohlížeč.
- Se sadou SDK zprostředkovatele: Aplikace ručně přihlásí uživatele k poskytovateli a pak odešle ověřovací token App Service k ověření. To je obvykle případ aplikací bez prohlížeče, které nemůžou uživateli prezentovat přihlašovací stránku poskytovatele. Kód aplikace spravuje proces přihlášení, takže se označuje také jako tok řízený klientem nebo tok klienta. Tento případ se týká rozhraní REST API, Azure Functions a javascriptových prohlížečových klientů a také aplikací prohlížeče, které vyžadují větší flexibilitu při přihlašování. Vztahuje se také na nativní mobilní aplikace, které přihlašují uživatele pomocí sady SDK poskytovatele.
Volání z důvěryhodné aplikace prohlížeče v App Service do jiného rozhraní REST API v App Service nebo Azure Functions je možné ověřit pomocí toku orientovaného na server. 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 | Se sadou SDK zprostředkovatele |
---|---|---|
1. Přihlášení uživatele | Přesměruje klienta na /.auth/login/<provider> . |
Klientský kód přihlásí uživatele přímo pomocí sady SDK zprostředkovatele a obdrží ověřovací token. Informace najdete v dokumentaci k poskytovateli. |
2. Po ověření | Zprostředkovatel přesměruje klienta na /.auth/login/<provider>/callback . |
Kód klienta odesílá token od zprostředkovatele do /.auth/login/<provider> za účelem ověření. |
3. Navázání ověřené relace | App Service přidá do odpovědi ověřený soubor cookie. | App Service vrátí do kódu klienta vlastní ověřovací token. |
4. Poskytování ověřeného obsahu | Klient zahrne ověřovací soubor cookie do následných požadavků (automaticky zpracovávaných prohlížečem). | Kód klienta zobrazí 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>
. Uživatelům můžete také nabídnout jeden nebo více /.auth/login/<provider>
odkazů pro přihlášení k aplikaci pomocí zvoleného poskytovatele.
Chování autorizace
Důležité
Ve výchozím nastavení tato funkce poskytuje pouze ověřování, ne autorizaci. Kromě kontrol, které tady nakonfigurujete, může vaše aplikace dál potřebovat provádět rozhodnutí o autorizaci.
V Azure Portal můžete nakonfigurovat App Service s řadou chování, když příchozí požadavek není ověřený. Následující nadpisy popisují možnosti.
Povolit neověřené požadavky
Tato možnost odblokuje autorizaci neověřeného provozu do kódu aplikace. U ověřených požadavků App Service také předávat 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 zprostředkovatelů přihlašování . Musíte ale napsat kód.
Vyžadovat ověřování
Tato možnost odmítne všechny neověřené přenosy do vaší aplikace. Toto odmítnutí může být akcí přesměrování na některého z nakonfigurovaných zprostředkovatelů identity. V těchto případech je klient prohlížeče přesměrován na /.auth/login/<provider>
poskytovatele, který zvolíte. Pokud anonymní požadavek pochází z nativní mobilní aplikace, je vrácená odpověď .HTTP 401 Unauthorized
Zamítnutí můžete také nakonfigurovat tak, aby bylo HTTP 401 Unauthorized
HTTP 403 Forbidden
nebo pro všechny požadavky.
S touto možností nemusíte do aplikace psát žádný ověřovací kód. Podrobnější autorizace, jako je autorizace specifická pro roli, se dá zpracovat kontrolou deklarací deklarací identity uživatele (viz Přístup k deklaracím identity uživatelů).
Upozornění
Omezení přístupu tímto způsobem se vztahuje na všechna volání vaší aplikace, což nemusí být žádoucí pro aplikace, které chtějí veřejně dostupnou domovskou stránku, jako v mnoha jednostránkových aplikacích.
Poznámka
Při použití zprostředkovatele identity Microsoft pro uživatele ve vaší organizaci je výchozím chováním, že každý uživatel ve vašem Azure AD tenantovi může požádat o token pro vaši aplikaci. Aplikaci můžete nakonfigurovat v Azure AD, pokud chcete omezit přístup k aplikaci na definovanou sadu uživatelů. App Service také nabízí některé základní předdefinované kontroly autorizace, které můžou pomoct s některými ověřeními. Další informace o autorizaci v Microsoft identity platform najdete v tématu základy autorizace Microsoft identity platform.
Úložiště tokenů
App Service poskytuje integrované úložiště tokenů, což je úložiště tokenů přidružených k 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:
- publikovat na časovou osu Facebooku ověřeného uživatele
- čtení podnikových dat uživatele pomocí Graph API Microsoftu
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ů jednoduše načtete tokeny, když je potřebujete, a řeknete App Service, aby je aktualizoval, když se stanou neplatnými.
Tokeny ID, přístupové tokeny a obnovovací tokeny se pro ověřenou relaci ukládají do mezipaměti a jsou přístupné jenom přidruženému uživateli.
Pokud v aplikaci nepotřebujete pracovat s tokeny, můžete úložiště tokenů zakázat na stránce Ověřování/autorizace vaší aplikace.
Protokolování a trasování
Pokud povolíte protokolování aplikace, uvidíte přímo v souborech protokolu trasování ověřování a autorizace. Pokud se zobrazí chyba ověřování, kterou jste nečekali, můžete pohodlně 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í Azure App Service se snadným ověřováním za službou Azure Front Door nebo jinými reverzními proxy servery je potřeba vzít v úvahu několik dalších věcí.
Zákaz 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 a zakázat ukládání do mezipaměti pro ověřování a stránky související s autorizací, najdete v tématu Zákaz mezipaměti pro pracovní postup ověřování .
Použití koncového bodu služby Front Door pro přesměrování
App Service obvykle není při zveřejnění prostřednictvím služby Azure Front Door přístupná přímo. Můžete tomu zabránit, například zveřejněním App Service prostřednictvím Private Link ve službě Azure Front Door Premium. Pokud chcete zabránit tomu, aby pracovní postup ověřování přesměrovává provoz zpět na App Service přímo, 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 App Service používá správný identifikátor URI přesměrování.
V některých konfiguracích používá App Service jako identifikátor URI přesměrování App Service plně kvalifikovaný název domény místo plně kvalifikovaného názvu domény služby Front Door. To povede k problému, když se klient přesměruje na App Service místo na Front Door. Pokud to chcete změnit,
forwardProxy
musí být nastavení nastavené naStandard
, aby App Service respektovaly hlavičkuX-Forwarded-Host
nastavenou službou Azure Front Door.Jiné reverzní proxy servery, jako jsou Azure Application Gateway nebo produkty třetích stran, můžou používat jiné hlavičky a vyžadují jiné nastavení forwardProxy.
Tuto konfiguraci nelze provést prostřednictvím Azure Portal a je tř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í
Hledat
"httpSettings": { "forwardProxy": { "convention": "Standard" } }
a ujistěte se, že je nastavená tak
Standard
,convention
aby respektovala hlavičkuX-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ší zdroje informací
- Postupy: Konfigurace aplikace App Service nebo Azure Functions tak, aby používala přihlášení Azure AD
- Přizpůsobení přihlášení a odhlašování
- Práce s tokeny A relacemi OAuth
- Přístup k deklaracím identity uživatelů a aplikací
- Konfigurace založená na souborech
Vzorky:
- Kurz: Přidání ověřování do webové aplikace spuštěné na Azure App Service
- Kurz: Kompletní ověřování a autorizace uživatelů v Azure App Service (Windows nebo Linux)
- Integrace .NET Core se službou Azure AppService EasyAuth (třetí strana)
- Jak Azure App Service ověřování funguje s .NET Core (třetí strana)