Ověřování a autorizace v Azure App Service a Azure Functions

  • Článek

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
Facebook /.auth/login/facebook App Service přihlášení k Facebooku
Google /.auth/login/google přihlášení App Service Google
Twitter /.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í

Tok ověřování

Chování autorizace

Úložiště tokenů

Protokolování a trasování

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.

Diagram architektury znázorňující požadavky zachycené procesem v sandboxu webu, který komunikuje se zprostředkovateli identit před povolením provozu do nasazené lokality

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 UnauthorizedHTTP 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í.

  1. 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í .

  2. 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.

  3. 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čku X-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á takStandard, convention aby 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ší zdroje informací

Vzorky: