Verificatie en autorisatie in Azure App Service en Azure Functions
Azure App Service biedt ingebouwde verificatie- en autorisatiemogelijkheden (ook wel 'Easy Auth' genoemd), zodat u gebruikers kunt aanmelden en toegang kunt krijgen tot gegevens 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 verificatie en autorisatie voor uw app kunt vereenvoudigen.
Waarom de ingebouwde verificatie gebruiken?
U bent niet verplicht om deze functie te gebruiken voor verificatie en autorisatie. U kunt de gebundelde beveiligingsfuncties gebruiken in uw web-framework naar keuze 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 bieden van toegang tot beveiligde gegevens) kan aanzienlijke inspanningen kosten. U moet ervoor zorgen dat u de best practices en standaarden in de branche volgt en uw implementatie up-to-date houdt. De ingebouwde verificatiefunctie voor App Service en Azure Functions kan u tijd en moeite besparen door out-of-the-box-verificatie te bieden met federatief id-providers, zodat u zich kunt richten op de rest van uw toepassing.
- Azure App Service kunt u tal van auth-mogelijkheden 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 geen code om te gebruiken.
- U kunt integreren met meerdere aanmeldingsproviders. Bijvoorbeeld Azure AD, Facebook, Google, Twitter.
Id-providers
App Service maakt gebruik vanfederatief identiteit, waarbij een id-provider van derden de gebruikersidentiteiten en verificatiestroom voor u beheert. De volgende id-providers zijn standaard beschikbaar:
| Provider | Aanmeldings-eindpunt | How-To richtlijnen |
|---|---|---|
| Microsoft Identity Platform | /.auth/login/aad |
App Service Microsoft Identity Platform-aanmelding |
/.auth/login/facebook |
App Service Facebook-aanmelding | |
/.auth/login/google |
App Service Google-aanmelding | |
/.auth/login/twitter |
App Service Twitter-aanmelding | |
| Een OpenID-Verbinding maken provider | /.auth/login/<providerName> |
App Service OpenID-Verbinding maken aanmelden |
Wanneer u verificatie en autorisatie bij een van deze providers inschakelen, is het aanmeldings-eindpunt beschikbaar voor gebruikersverificatie en voor validatie van verificatietokens van de provider. U kunt uw gebruikers elk aantal van deze aanmeldingsopties bieden.
Overwegingen voor het gebruik van ingebouwde verificatie
Als u deze functie inschakelen, worden alle aanvragen naar uw toepassing automatisch omgeleid naar HTTPS, ongeacht de configuratie-instelling App Service https wordt afgedwongen. U kunt dit uitschakelen met de requireHttps instelling in de V2-configuratie. We raden u echter aan https te gebruiken en u moet ervoor zorgen dat er nooit beveiligingstokens worden verzonden via niet-beveiligde HTTP-verbindingen.
App Service kunnen 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 die moet worden ondernomen wanneer de aanvraag niet is geverifieerd om zich aan te melden bij een van de geconfigureerde id-providers. Als u de toegang wilt verifiëren maar niet wilt beperken, stelt u Actie die moet worden ondernomen wanneer de aanvraag niet is geverifieerd in op Anonieme aanvragen toestaan (geen actie).
Notitie
U moet elke app-registratie een eigen machtiging en toestemming geven. Vermijd het delen van machtigingen tussen omgevingen door afzonderlijke app-registraties te gebruiken voor afzonderlijke implementatiesleuven. Bij het testen van nieuwe code kan deze praktijk helpen voorkomen dat problemen van invloed zijn op de productie-app.
Uitleg
Logboekregistratie en tracering
Functiearchitectuur
Het middleware-onderdeel voor verificatie en autorisatie is een functie van het platform dat wordt uitgevoerd op dezelfde VM als uw toepassing. Wanneer deze is ingeschakeld, wordt deze door elke binnenkomende HTTP-aanvraag verwerkt voordat deze door uw toepassing wordt verwerkt.
De platform-middleware verwerkt verschillende zaken voor uw app:
- Verifieert gebruikers en clients met de opgegeven id-provider(s)
- Valideert, bewaart 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 Azure Resource Manager instellingen of met behulp van een configuratiebestand. Er zijn geen SDK's, specifieke programmeertalen of wijzigingen in uw toepassingscode vereist.
Functiearchitectuur op 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 deze door elke binnenkomende HTTP-aanvraag verwerkt voordat deze door uw toepassing wordt verwerkt.
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 op Windows. Omdat deze niet in-process wordt uitgevoerd, is er geen directe integratie met specifieke taalkaders 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 verschilt afhankelijk van of u zich wilt aanmelden met de SDK van de provider:
- Zonder provider-SDK: de toepassing delegeert federatief aanmelden aan 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 het wordt ook wel een servergestuurde stroom of serverstroom genoemd. Dit geval is van toepassing op browser-apps. Het is ook van toepassing op native apps die gebruikers aanmelden met behulp van de Mobile Apps client-SDK, 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 verstuurt het verificatie-token vervolgens 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 het wordt ook wel clientgestuurde stroom of clientstroom genoemd. Dit geval is van toepassing op REST API's, Azure Functionsen JavaScript-browser-clients, evenals browser-apps die meer flexibiliteit in het aanmeldingsproces nodig hebben. Het is ook van toepassing op native 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 aanmeldingen aanpassenvoor meer informatie.
In de onderstaande tabel ziet u de stappen van de verificatiestroom.
| Stap | Zonder provider-SDK | Met provider-SDK |
|---|---|---|
| 1. Gebruiker aanmelden | Leidt de client om naar /.auth/login/<provider> . |
Clientcode meldt de gebruiker rechtstreeks aan bij de SDK van de provider en ontvangt een verificatie-token. Zie de documentatie van de provider voor meer informatie. |
| 2. Na verificatie | Provider leidt client om naar /.auth/login/<provider>/callback . |
Clientcode plaatst een token van provider naar voor /.auth/login/<provider> validatie. |
| 3. Geverifieerde sessie tot stand | App Service voegt geverifieerde cookie toe aan het antwoord. | App Service retourneert een eigen verificatie-token naar clientcode. |
| 4. Geverifieerde inhoud leveren | Client bevat verificatiecookie in volgende aanvragen (automatisch verwerkt door browser). | Clientcode presenteert verificatie-token in X-ZUMO-AUTH header (automatisch verwerkt door Mobile Apps client-SDK's). |
Voor clientbrowsers App Service alle niet-geautheticeerde gebruikers automatisch om leiden naar /.auth/login/<provider> . U kunt gebruikers ook een of meer koppelingen bieden om zich aan te melden bij uw app met /.auth/login/<provider> hun provider naar keuze.
Autorisatiegedrag
In de Azure Portalkunt u een App Service configureren met een aantal gedragingen wanneer een binnenkomende aanvraag niet wordt geverifieerd. In de volgende koppen worden de opties beschreven.
Niet-geautheseerde aanvragen toestaan
Met deze optie wordt de autorisatie van niet-geautheticeerd 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 presenteren aan uw gebruikers. U moet echter wel code schrijven.
Verificatie vereisen
Met deze optie wordt niet-geautticeerd verkeer naar uw toepassing afgewezen. Deze afwijzing kan een omleidingsactie zijn naar een van de geconfigureerde id-providers. In dergelijke gevallen wordt een browserclient omgeleid /.auth/login/<provider> naar voor de provider die u kiest. Als de anonieme aanvraag afkomstig is van een native mobiele app, is het geretourneerde antwoord een HTTP 401 Unauthorized . U kunt de afwijzing ook configureren als een HTTP 401 Unauthorized of HTTP 403 Forbidden voor alle aanvragen.
Met deze optie hoeft u geen verificatiecode in uw app te schrijven. Fijner autorisatie, zoals rolspecifieke autorisatie, kan worden verwerkt door de claims van de gebruiker te controleren (zie Gebruikersclaims openen).
Waarschuwing
De toegang op deze manier beperken 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 ingebouwde tokenopslag. Dit is een opslagplaats met tokens die zijn gekoppeld aan de gebruikers van uw web-apps, API's of systeemeigen mobiele apps. Wanneer u verificatie bij een provider inschakelen, is deze tokenopslag onmiddellijk beschikbaar voor uw app. Als uw toepassingscode namens de gebruiker toegang moet hebben tot gegevens van deze providers, zoals:
- op de Facebook-tijdlijn van de geverifieerde gebruiker plaatsen
- zakelijke gegevens van de gebruiker lezen met behulp van de Microsoft Graph-API
Normaal gesproken moet u code schrijven om deze tokens in uw toepassing te verzamelen, op te slaan en te vernieuwen. Met het tokenopslag haalt u de tokens op wanneer u ze nodig hebt en laat u App Service 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 gekoppelde gebruiker.
Als u niet met tokens in uw app hoeft te werken, kunt u het tokenopslag uitschakelen op de pagina Verificatie/autorisatie van uw app.
Logboekregistratie en tracering
Als u toepassingslogboekregistratie inschakelen,ziet u verificatie- en autorisatie-traceringen rechtstreeks in uw logboekbestanden. Als er een verificatiefout wordt weergegeven die u niet had verwacht, kunt u alle details gemakkelijk vinden door te kijken in uw bestaande toepassingslogboeken. Als u tracering van mislukte aanvragen inschakelen,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 .
Meer bronnen
- How-To: Configureer uw App Service of Azure Functions-app voor het gebruik van Azure AD-aanmelding
- Aanmeldingen en aanmeldingen aanpassen
- Werken met OAuth-tokens en -sessies
- Toegang tot gebruikers- en toepassingsclaims
- Configuratie op basis van bestanden
Monsters:
- Zelfstudie: Verificatie toevoegen aan uw web-app die wordt uitgevoerd in Azure App Service
- Zelfstudie: Gebruikers end-to-end verifiëren en autoriseren in Azure App Service (Windows of Linux)
- .NET Core-integratie van Azure AppService EasyAuth (externe partij)
- Verificatie Azure App Service met .NET Core (derden)