Verificatie en autorisatie in Azure App Service en Azure Functions

Artikel
11/29/2022
10 minuten om te lezen

Azure App Service biedt ingebouwde verificatie- en autorisatiemogelijkheden (ook wel 'Eenvoudige verificatie' genoemd), zodat u gebruikers kunt aanmelden en gegevens kunt openen door minimale of geen code te schrijven in uw web-app, RESTful-API en mobiele back-end, en ook Azure Functions. In dit artikel wordt beschreven hoe App Service helpt verificatie en autorisatie voor uw app te vereenvoudigen.

Waarom de ingebouwde verificatie gebruiken?

U hoeft deze functie niet te gebruiken voor verificatie en autorisatie. U kunt de gebundelde beveiligingsfuncties in uw webframework van keuze gebruiken of u kunt uw eigen hulpprogramma's schrijven. U moet er echter voor zorgen dat uw oplossing up-to-date blijft met de nieuwste beveiligings-, protocol- en browserupdates.

Het implementeren van een veilige oplossing voor verificatie (aanmeldingsgebruikers) en autorisatie (het verlenen van toegang tot beveiligde gegevens) kan veel moeite kosten. U moet ervoor zorgen dat u best practices en standaarden voor de branche volgt en uw implementatie up-to-date houdt. Met de ingebouwde verificatiefunctie voor App Service en Azure Functions kunt u tijd en moeite besparen door kant-en-klare verificatie te bieden met federatieve id-providers, zodat u zich kunt richten op de rest van uw toepassing.

Azure App Service kunt u verschillende verificatiemogelijkheden integreren in uw web-app of API zonder ze zelf te implementeren.
Het is rechtstreeks ingebouwd in het platform en vereist geen specifieke taal, SDK, beveiligingsexpertise of zelfs code die moet worden gebruikt.
U kunt integreren met meerdere aanmeldingsproviders. Bijvoorbeeld Azure AD, Facebook, Google, Twitter.

Id-providers

App Service federatieve identiteit gebruikt, waarbij een externe id-provider de gebruikersidentiteiten en verificatiestroom voor u beheert. De volgende id-providers zijn standaard beschikbaar:

Provider	Aanmeldingseindpunt	How-To richtlijnen
Microsoft Identity Platform	`/.auth/login/aad`	aanmelding bij Microsoft Identity Platform App Service
Facebook	`/.auth/login/facebook`	Aanmelden bij Facebook App Service
Google	`/.auth/login/google`	App Service Google-aanmelding
Twitter	`/.auth/login/twitter`	Aanmelden bij Twitter App Service
Elke OpenID Connect-provider	`/.auth/login/<providerName>`	aanmelding bij App Service OpenID Connect

Wanneer u verificatie en autorisatie inschakelt bij een van deze providers, is het aanmeldingseindpunt beschikbaar voor gebruikersverificatie en voor validatie van verificatietokens van de provider. U kunt uw gebruikers een willekeurig aantal van deze aanmeldingsopties bieden.

Overwegingen voor het gebruik van ingebouwde verificatie

Als u deze functie inschakelt, worden alle aanvragen voor uw toepassing automatisch omgeleid naar HTTPS, ongeacht de App Service configuratie-instelling om HTTPS af te dwingen. U kunt dit uitschakelen met de requireHttps instelling in de V2-configuratie. We raden u echter aan om te blijven hangen met HTTPS en u moet ervoor zorgen dat er nooit beveiligingstokens worden verzonden via niet-beveiligde HTTP-verbindingen.

App Service kan worden gebruikt voor verificatie met of zonder de toegang tot uw site-inhoud en API's te beperken. Als u de toegang tot apps alleen wilt beperken tot geverifieerde gebruikers, stelt u Actie in die moet worden uitgevoerd wanneer de aanvraag niet wordt geverifieerd om u aan te melden met een van de geconfigureerde id-providers. Als u de toegang wilt verifiëren maar niet wilt beperken, stelt u actie in die moet worden uitgevoerd wanneer de aanvraag niet is geverifieerd bij 'Anonieme aanvragen toestaan (geen actie).'

Notitie

U moet elke app-registratie een eigen machtiging en toestemming geven. Vermijd het delen van machtigingen tussen omgevingen met behulp van afzonderlijke app-registraties voor afzonderlijke implementatiesites. Bij het testen van nieuwe code kan deze procedure helpen voorkomen dat problemen van invloed zijn op de productie-app.

Uitleg

Logboekregistratie en tracering

Functiearchitectuur

Het onderdeel verificatie- en autorisatie-middleware is een functie van het platform dat wordt uitgevoerd op dezelfde VM als uw toepassing. Wanneer deze is ingeschakeld, wordt elke binnenkomende HTTP-aanvraag doorgegeven voordat deze wordt verwerkt door uw toepassing.

De platform-middleware verwerkt verschillende dingen voor uw app:

Verifieert gebruikers en clients met de opgegeven id-provider(s)
Valideert, slaat en vernieuwt OAuth-tokens die zijn uitgegeven door de geconfigureerde id-provider(s)
Beheert de geverifieerde sessie
Injecteert identiteitsgegevens in HTTP-aanvraagheaders

De module wordt afzonderlijk van uw toepassingscode uitgevoerd en kan worden geconfigureerd met behulp van Azure Resource Manager-instellingen of met behulp van een configuratiebestand. Er zijn geen SDK's, specifieke programmeertalen of wijzigingen in uw toepassingscode vereist.

Functiearchitectuur in Windows (niet-containerimplementatie)

De verificatie- en autorisatiemodule wordt uitgevoerd als een systeemeigen IIS-module in dezelfde sandbox als uw toepassing. Wanneer deze is ingeschakeld, wordt elke binnenkomende HTTP-aanvraag doorgegeven voordat deze wordt verwerkt door uw toepassing.

Functiearchitectuur in Linux en containers

De verificatie- en autorisatiemodule wordt uitgevoerd in een afzonderlijke container, geïsoleerd van uw toepassingscode. Met behulp van wat bekend staat als het Ambassador-patroon, communiceert het met het binnenkomende verkeer om vergelijkbare functionaliteit uit te voeren als in Windows. Omdat het niet in proces wordt uitgevoerd, is er geen directe integratie met specifieke taalframeworks mogelijk; De relevante informatie die uw app nodig heeft, wordt echter doorgegeven met behulp van aanvraagheaders, zoals hieronder wordt uitgelegd.

Verificatiestroom

De verificatiestroom is hetzelfde voor alle providers, maar is afhankelijk van of u zich wilt aanmelden met de SDK van de provider:

Zonder provider-SDK: de toepassing delegeert federatieve aanmelding naar App Service. Dit is meestal het geval bij browser-apps, die de aanmeldingspagina van de provider aan de gebruiker kunnen presenteren. De servercode beheert het aanmeldingsproces, dus dit wordt ook wel servergestuurde stroom of serverstroom genoemd. Dit geval is van toepassing op browser-apps. Het is ook van toepassing op systeemeigen apps die gebruikers aanmelden met de SDK voor de Mobile Apps-client, omdat de SDK een webweergave opent om gebruikers aan te melden met App Service-verificatie.
Met provider-SDK: De toepassing meldt gebruikers handmatig aan bij de provider en verzendt vervolgens het verificatietoken naar App Service voor validatie. Dit is meestal het geval bij apps zonder browser, die de aanmeldingspagina van de provider niet aan de gebruiker kunnen presenteren. De toepassingscode beheert het aanmeldingsproces, dus dit wordt ook wel clientgestuurde stroom of clientstroom genoemd. Dit geval is van toepassing op REST API's, Azure Functions en JavaScript-browserclients, evenals browser-apps die meer flexibiliteit nodig hebben in het aanmeldingsproces. Het is ook van toepassing op systeemeigen mobiele apps die gebruikers aanmelden met behulp van de SDK van de provider.

Aanroepen van een vertrouwde browser-app in App Service naar een andere REST API in App Service of Azure Functions kunnen worden geverifieerd met behulp van de servergestuurde stroom. Zie Aanmeldingen en afmeldingen aanpassen voor meer informatie.

In de onderstaande tabel ziet u de stappen van de verificatiestroom.

Stap	Zonder provider-SDK	Met provider-SDK
1. Gebruiker aanmelden	Stuurt de client om naar `/.auth/login/<provider>`.	Clientcode meldt de gebruiker rechtstreeks aan met de SDK van de provider en ontvangt een verificatietoken. Zie de documentatie van de provider voor meer informatie.
2. Na verificatie	Provider leidt de client om naar `/.auth/login/<provider>/callback`.	Clientcode plaatst token van provider naar `/.auth/login/<provider>` voor validatie.
3. Geverifieerde sessie tot stand brengen	App Service voegt geverifieerde cookie toe aan het antwoord.	App Service retourneert een eigen verificatietoken naar clientcode.
4. Geverifieerde inhoud leveren	Client bevat verificatiecooky in volgende aanvragen (automatisch verwerkt door browser).	Clientcode presenteert verificatietoken in `X-ZUMO-AUTH` header (automatisch verwerkt door Mobile Apps-client-SDK's).

Voor clientbrowsers kan App Service automatisch alle niet-geverifieerde gebruikers doorsturen naar /.auth/login/<provider>. U kunt gebruikers ook presenteren met een of meer /.auth/login/<provider> koppelingen om u aan te melden bij uw app met behulp van hun provider van keuze.

Autorisatiegedrag

In de Azure Portal kunt u App Service configureren met een aantal gedragingen wanneer binnenkomende aanvragen niet worden geverifieerd. In de volgende koppen worden de opties beschreven.

Niet-geverifieerde aanvragen toestaan

Met deze optie wordt de autorisatie van niet-geverifieerd verkeer naar uw toepassingscode uitgesteld. Voor geverifieerde aanvragen geeft App Service ook verificatiegegevens door in de HTTP-headers.

Deze optie biedt meer flexibiliteit bij het verwerken van anonieme aanvragen. Hiermee kunt u bijvoorbeeld meerdere aanmeldingsproviders aan uw gebruikers presenteren. U moet echter code schrijven.

Verificatie vereisen

Met deze optie wordt niet-geverifieerd verkeer naar uw toepassing geweigerd. Deze afwijzing kan een omleidingsactie zijn naar een van de geconfigureerde id-providers. In deze gevallen wordt een browserclient omgeleid naar /.auth/login/<provider> de provider die u kiest. Als de anonieme aanvraag afkomstig is van een systeemeigen mobiele app, is het geretourneerde antwoord een HTTP 401 Unauthorized. U kunt de afwijzing ook zo configureren dat deze een HTTP 401 Unauthorized of HTTP 403 Forbidden voor alle aanvragen is.

Met deze optie hoeft u geen verificatiecode in uw app te schrijven. Finer-autorisatie, zoals rolspecifieke autorisatie, kan worden verwerkt door de claims van de gebruiker te inspecteren (zie Access-gebruikersclaims).

Waarschuwing

Het beperken van de toegang op deze manier is van toepassing op alle aanroepen naar uw app, wat mogelijk niet wenselijk is voor apps die een openbaar beschikbare startpagina willen, zoals in veel toepassingen met één pagina.

Notitie

Standaard kan elke gebruiker in uw Azure AD tenant een token voor uw toepassing aanvragen bij Azure AD. U kunt de toepassing in Azure AD configureren als u de toegang tot uw app wilt beperken tot een gedefinieerde set gebruikers.

Tokenarchief

App Service biedt een ingebouwd tokenarchief, een opslagplaats met tokens die zijn gekoppeld aan de gebruikers van uw web-apps, API's of systeemeigen mobiele apps. Wanneer u verificatie inschakelt bij een provider, is dit tokenarchief onmiddellijk beschikbaar voor uw app. Als uw toepassingscode namens de gebruiker toegang moet hebben tot gegevens van deze providers, zoals:

posten op de Facebook-tijdlijn van de geverifieerde gebruiker
de bedrijfsgegevens van de gebruiker lezen met behulp van de Microsoft-Graph API

Doorgaans moet u code schrijven om deze tokens in uw toepassing te verzamelen, op te slaan en te vernieuwen. Met het tokenarchief haalt u alleen de tokens op wanneer u ze nodig hebt en geeft u App Service om ze te vernieuwen wanneer ze ongeldig worden.

De id-tokens, toegangstokens en vernieuwingstokens worden in de cache opgeslagen voor de geverifieerde sessie en zijn alleen toegankelijk voor de bijbehorende gebruiker.

Als u niet met tokens in uw app hoeft te werken, kunt u het tokenarchief uitschakelen op de pagina Verificatie/autorisatie van uw app.

Logboekregistratie en tracering

Als u toepassingslogboekregistratie inschakelt, ziet u verificatie- en autorisatietraceringen rechtstreeks in uw logboekbestanden. Als u een verificatiefout ziet die u niet had verwacht, kunt u gemakkelijk alle details vinden door in uw bestaande toepassingslogboeken te zoeken. Als u tracering van mislukte aanvragen inschakelt, kunt u precies zien welke rol de verificatie- en autorisatiemodule mogelijk heeft gespeeld in een mislukte aanvraag. Zoek in de traceerlogboeken naar verwijzingen naar een module met de naam EasyAuthModule_32/64.

Overwegingen bij het gebruik van Azure Front Door

Wanneer u Azure App Service gebruikt met Easy Auth achter Azure Front Door of andere omgekeerde proxy's, moet u rekening houden met enkele extra zaken.

Caching uitschakelen voor de verificatiewerkstroom

Zie Cache uitschakelen voor verificatiewerkstroom voor meer informatie over het configureren van regels in Azure Front Door om caching voor verificatie- en autorisatiegerelateerde pagina's uit te schakelen.
Het Front Door-eindpunt gebruiken voor omleidingen

App Service is meestal niet rechtstreeks toegankelijk wanneer deze toegankelijk is via Azure Front Door. Dit kan bijvoorbeeld worden voorkomen door App Service beschikbaar te maken via Private Link in Azure Front Door Premium. Om te voorkomen dat de verificatiewerkstroom verkeer omleidt naar App Service rechtstreeks, is het belangrijk om de toepassing te configureren om terug te leiden naar https://<front-door-endpoint>/.auth/login/<provider>/callback.
Zorg ervoor dat App Service de juiste omleidings-URI gebruikt

In sommige configuraties gebruikt de App Service de App Service FQDN als omleidings-URI in plaats van de Front Door-FQDN. Dit leidt tot een probleem wanneer de client wordt omgeleid naar App Service in plaats van Front Door. Als u dit wilt wijzigen, moet de forwardProxy instelling zo worden ingesteld Standard dat App Service de X-Forwarded-Host koptekst die door Azure Front Door is ingesteld, respecteert.

Andere omgekeerde proxy's, zoals Azure Application Gateway of producten van derden, kunnen verschillende headers gebruiken en een andere forwardProxy-instelling nodig hebben.

Deze configuratie kan momenteel niet worden uitgevoerd via de Azure Portal en moet worden uitgevoerd viaaz rest:

Exportinstellingen

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

Update-instellingen

Zoeken naar
```
"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}
```
en zorg ervoor dat deze is ingesteld om de X-Forwarded-Host header te Standard respecteren die convention wordt gebruikt door Azure Front Door.

Importinstellingen

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

Meer bronnen

Monsters: