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 Easy Auth), takže můžete přihlašovat uživatele a přistupovat k datům tak, že ve webové aplikaci, rozhraní RESTful API a mobilním back-endu napíšete minimální nebo žádný kód a také Azure Functions. Tento článek popisuje, App Service zjednodušuje ověřování a autorizaci pro vaši aplikaci.
Proč používat integrované ověřování?
Tuto funkci není nutné používat k ověřování a autorizaci. Můžete použít seskupené funkce zabezpečení ve webovém rozhraní podle vlastního výběru nebo můžete psát 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řihlašování uživatelů) a autorizaci (poskytování přístupu k zabezpečeným datům) může trvat značné úsilí. Musíte dodržovat osvědčené postupy a standardy v oboru a udržovat implementaci v aktuálních 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 vám předem poskytne ověřování pomocí federovaných zprostředkovatelů identit, což vám umožní soustředit se na zbytek vaší aplikace.
- Azure App Service umožňuje integrovat do webové aplikace nebo rozhraní API celou řadu funkcí ověřování, aniž byste je sami implementací implementují.
- Je přímo integrovaná do platformy a nevyžaduje použití žádného konkrétního jazyka, sady SDK, odborných znalostí zabezpečení ani kódu.
- Můžete se integrovat s několika poskytovateli přihlášení. Například Azure AD, Facebook, Google, Twitter.
Zprostředkovatelé identit
App Service používá federovanou identitu, ve které zprostředkovatel identity třetí strany spravuje identity uživatelů a tok ověřování za vás. Ve výchozím nastavení jsou k dispozici následující zprostředkovatelé identity:
| Poskytovatel | Koncový bod přihlášení | How-To pokyny |
|---|---|---|
| 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 |
App Service google | |
/.auth/login/twitter |
App Service přihlášení k Twitteru | |
| Jakýkoli poskytovatel Připojení OpenID | /.auth/login/<providerName> |
App Service přihlášení Připojení OpenID |
Když u jednoho z těchto poskytovatelů povolíte ověřování a autorizaci, bude jeho přihlašovací koncový bod k dispozici pro ověřování uživatelů a ověřování ověřovacích tokenů od poskytovatele. 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í App Service, které vynucuje HTTPS. Můžete to 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 ověřování s omezením přístupu k obsahu webu a rozhraním API nebo bez něj. 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ěřuje, aby se přihlašoval pomocí jednoho z nakonfigurovaných zprostředkovatelů identity. Pokud chcete ověřit přístup, ale ne omezit přístup, nastavte akci, která se má provést, když se požadavek neověřuje, na Povolit anonymní požadavky (žádná akce).
Poznámka
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 v ovlivnění produkční aplikace.
Jak to funguje
Architektura funkcí
Ověřovací a autorizační middlewarová komponenta je funkce platformy, která běží na stejném virtuálním počítači jako vaše aplikace. Když je tato možnost povolená, před zpracováním vaší aplikací přes něj projde každý příchozí požadavek HTTP.
Middleware platformy zpracovává pro vaši aplikaci 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ých zprostředkovateli identity.
- Spravuje ověřenou relaci.
- Vloží informace o identitě do hlaviček požadavku HTTP.
Modul se spouští odděleně od kódu vaší aplikace a je možné ho nakonfigurovat Azure Resource Manager nastavení 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í v Windows (nasazení bez kontejnerů)
Modul ověřování a autorizace se spouští jako nativní modul služby IIS ve stejném sandboxu jako vaše aplikace. Když je tato možnost povolená, před zpracováním vaší aplikací přes něj projde každý příchozí požadavek HTTP.
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 ambasador komunikuje s příchozím provozem a provádí podobné funkce jako na Windows. Vzhledem k tomu, že se nespouštěl v procesu, není možná žádná přímá integrace s konkrétními jazykovou architekturou. Relevantní informace, které vaše aplikace potřebuje, se ale předá pomocí hlaviček požadavků, jak je vysvětleno níže.
Tok ověřování
Tok ověřování je pro všechny poskytovatele stejný, 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 se obvykle týká aplikací v prohlížeči, které mohou uživateli prezentovat přihlašovací stránku poskytovatele. Kód serveru spravuje proces přihlašování, takže se také nazývá tok směrovaný na server nebo tok serveru. Tento případ platí pro aplikace v prohlížeči. Platí to také pro nativní aplikace, které přihlašovat uživatele pomocí klientské sady SDK Mobile Apps, protože sada SDK otevře webové zobrazení pro přihlášení uživatelů pomocí App Service ověřování.
- Pomocí sady SDK zprostředkovatele: Aplikace přihlásí uživatele k poskytovateli ručně a potom odešle ověřovací token App Service k ověření. To se obvykle týká aplikací bez prohlížeče, které uživateli neumže předložit přihlašovací stránku poskytovatele. Kód aplikace spravuje proces přihlašování, takže se také nazývá tok směrovaný na klienta nebo tok klienta. Tento případ se týká rozhraní REST API, Azure Functionsa javascriptových prohlížečů a také prohlížečových aplikací, které potřebují větší flexibilitu při přihlašování. Platí to také pro nativní mobilní aplikace, které uživatele přihlašjí pomocí sady SDK poskytovatele.
Volání z důvěryhodné aplikace prohlížeče App Service jiné REST API ve službě App Service nebo Azure Functions je možné ověřit pomocí toku směrové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 poskytovatele | Se sadou SDK poskytovatele |
|---|---|---|
| 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 poskytovatele. |
| 2. Ověření po ověření | Zprostředkovatel přesměruje klienta na /.auth/login/<provider>/callback . |
Klientský kód odešle token zprostředkovatele do k /.auth/login/<provider> ověření. |
| 3. Zřízení ověřené relace | App Service do odpovědi přidá ověřený soubor cookie. | App Service klientský kód vrátí vlastní ověřovací token. |
| 4. Obsloužit ověřený obsah | Klient zahrnuje ověřovací soubor cookie v následných požadavcích (automaticky zpracovaný prohlížečem). | Klientský kód prezentuje ověřovací token v X-ZUMO-AUTH hlavičce (automaticky zpracovává Mobile Apps klientských sdk). |
V klientských prohlížečích App Service automaticky přesměrovat všechny neověřené uživatele na /.auth/login/<provider> . Můžete taky prezentovat uživatele s jedním nebo více /.auth/login/<provider> odkazy pro přihlášení k aplikaci pomocí poskytovatele podle vlastního výběru.
Chování autorizace
V Azure Portalmůžete nakonfigurovat App Service s řadou chování, když příchozí žádost není ověřena. Tyto možnosti jsou popsány v následujících nadpisech.
Povolení neověřených požadavků
Tato možnost odloží autorizaci neověřeného provozu do kódu aplikace. U ověřených požadavků App Service také společně s ověřovacími informacemi v hlavičkách protokolu HTTP.
Tato možnost nabízí větší flexibilitu při zpracování anonymních požadavků. Například umožňuje uživatelům prezentovat více poskytovatelů přihlášení . Je však nutné napsat kód.
Vyžadovat ověření
Tato možnost způsobí zamítnutí všech neověřených přenosů do vaší aplikace. Toto odmítnutí může představovat akci přesměrování u jednoho z konfigurovaných zprostředkovatelů identity. V těchto případech je klient prohlížeče přesměrován na /.auth/login/<provider> pro poskytovatele, kterého zvolíte. Pokud anonymní požadavek pochází z nativní mobilní aplikace, vrácená odpověď je HTTP 401 Unauthorized . Můžete také nakonfigurovat odmítnutí pro HTTP 401 Unauthorized HTTP 403 Forbidden všechny požadavky.
Pomocí této možnosti nemusíte v aplikaci psát žádný ověřovací kód. Přesnější autorizaci, například autorizaci specifickou pro role, je možné zpracovat kontrolou deklarací identity uživatele (viz přístup k deklaracím uživatelů).
Upozornění
Omezení přístupu tímto způsobem se vztahuje na všechna volání aplikace, která nemusí být žádoucí pro aplikace, které mají veřejně dostupnou domovskou stránku, stejně jako v mnoha aplikacích s jednou stránkou.
Poznámka
Ve výchozím nastavení může každý uživatel ve vašem tenantovi Azure AD požádat o token vaší aplikace ze služby Azure AD. Pokud chcete omezit přístup k aplikaci na definovanou sadu uživatelů, můžete aplikaci ve službě Azure AD nakonfigurovat .
Úložiště tokenů
App Service poskytuje integrované úložiště tokenů, což je úložiště tokenů, které jsou přidružené k uživatelům webových aplikací, rozhraní API nebo nativních mobilních aplikací. Pokud povolíte ověřování u libovolného poskytovatele, je úložiště tokenů hned dostupné pro vaši aplikaci. Pokud kód aplikace potřebuje přístup k datům z těchto poskytovatelů jménem uživatele, například:
- odeslání příspěvku na časovou osu Facebooku ověřeného uživatele
- Přečtěte si podniková data uživatele pomocí rozhraní Microsoft Graph API.
Obvykle je nutné 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 sdělit App Service, že je budou aktualizovat , jakmile se stanou neplatnými.
Tokeny ID, přístupové tokeny a aktualizační tokeny jsou uloženy v mezipaměti pro ověřenou relaci a jsou přístupné pouze přidruženému uživateli.
Pokud nepotřebujete v aplikaci 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í aplikací, zobrazí se přímo v souborech protokolu trasování pro ověřování a autorizaci. Pokud se zobrazí chyba ověřování, kterou jste neočekávali, můžete pohodlně vyhledat všechny podrobnosti, a to tak, že budete hledat v existujících protokolech aplikací. Pokud povolíte trasování chybných požadavků, vidíte přesně to, jakou roli se modul ověřování a autorizace mohl přehrát v neúspěšném požadavku. V protokolech trasování vyhledejte odkazy na modul s názvem EasyAuthModule_32/64 .
Další zdroje informací
- Postupy: Konfigurace App Service nebo Azure Functions aplikace pro použití přihlášení služby Azure AD
- Přizpůsobení přihlašování a odhlašování
- Práce s tokeny a relacemi OAuth
- Přístup k deklaracím uživatelů a aplikací
- Konfigurace na základě souborů
Vzory