Uw App Service- of Azure Functions-app configureren voor het gebruik van Azure AD aanmelding

In dit artikel wordt beschreven hoe u verificatie configureert voor Azure App Service of Azure Functions, zodat uw app gebruikers met de Microsoft identity platform (Azure AD) aanmeldt als verificatieprovider.

De functie App Service Verificatie kan automatisch een app-registratie maken met de Microsoft identity platform. U kunt ook een registratie gebruiken die u of een directorybeheerder afzonderlijk maakt.

Notitie

De optie voor het maken van een nieuwe registratie is niet beschikbaar voor overheidsclouds. Definieer in plaats daarvan een registratie afzonderlijk.

Optie 1: Automatisch een nieuwe app-registratie maken

Deze optie is ontworpen om het inschakelen van verificatie eenvoudig te maken en vereist slechts een paar klikken.

  1. Meld u aan bij de Azure Portal en navigeer naar uw app.

  2. Selecteer Verificatie in het menu links. Klik op Id-provider toevoegen.

  3. Selecteer Microsoft in de vervolgkeuzelijst id-provider. De optie voor het maken van een nieuwe registratie is standaard geselecteerd. U kunt de naam van de registratie of de ondersteunde accounttypen wijzigen.

    Er wordt een clientgeheim gemaakt en opgeslagen als een site-sticky toepassingsinstelling met de naam MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. U kunt deze instelling later bijwerken om Key Vault-verwijzingen te gebruiken als u het geheim wilt beheren in Azure Key Vault.

  4. Als dit de eerste id-provider is die voor de toepassing is geconfigureerd, wordt u ook gevraagd om een App Service sectie verificatie-instellingen. Anders kunt u doorgaan met de volgende stap.

    Deze opties bepalen hoe uw toepassing reageert op niet-geverifieerde aanvragen en de standaardselecties leiden alle aanvragen om u aan te melden bij deze nieuwe provider. U kunt dit gedrag nu wijzigen of deze instellingen later aanpassen vanuit het hoofdscherm Verificatie door Bewerken naast Verificatie-instellingen te kiezen. Zie Verificatiestroom voor meer informatie over deze opties.

  5. (Optioneel) Klik op Volgende: Machtigingen en voeg eventuele bereiken toe die nodig zijn voor de toepassing. Deze worden toegevoegd aan de app-registratie, maar u kunt ze later ook wijzigen.

  6. Klik op Add.

U bent nu klaar om de Microsoft identity platform voor verificatie in uw app te gebruiken. De provider wordt weergegeven op het scherm Verificatie . Van daaruit kunt u deze providerconfiguratie bewerken of verwijderen.

Zie deze zelfstudie voor een voorbeeld van het configureren van Azure AD aanmelding voor een web-app die toegang heeft tot Azure Storage en Microsoft Graph.

Optie 2: Een bestaande registratie gebruiken die afzonderlijk is gemaakt

U kunt uw toepassing ook handmatig registreren voor de Microsoft identity platform, de registratie aanpassen en App Service Authentication configureren met de registratiegegevens. Dit is bijvoorbeeld handig als u een app-registratie wilt gebruiken van een andere Azure AD tenant dan de tenant waarin uw toepassing zich bevindt.

Een app-registratie maken in Azure AD voor uw App Service-app

Eerst maakt u uw app-registratie. Als u dit doet, verzamelt u de volgende informatie die u later nodig hebt wanneer u de verificatie configureert in de App Service-app:

  • Client-id
  • Tenant-id
  • Clientgeheim (optioneel)
  • URI voor de toepassings-id

Voer de volgende stappen uit om de app te registreren:

  1. Meld u aan bij de Azure Portal, zoek en selecteer App Services en selecteer uw app. Noteer de URL van uw app. U gebruikt deze om de registratie van uw Azure Active Directory-app te configureren.

  2. Selecteer Azure Active Directory in het portalmenu, ga naar het tabblad App-registraties en selecteer Nieuwe registratie.

  3. Voer op de pagina Een toepassing registreren een naam in voor uw app-registratie.

  4. Selecteer web in omleidings-URI en typ <app-url>/.auth/login/aad/callback. Bijvoorbeeld https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Selecteer Registreren.

  6. Nadat de app-registratie is gemaakt, kopieert u de toepassings-id (client) en de map-id (tenant) voor later gebruik.

  7. Selecteer Verificatie. Schakel onder Impliciete toekenning en hybride stromenid-tokens in om OpenID Connect-gebruikersaanmelding toe te staan vanuit App Service. Selecteer Opslaan.

  8. (Optioneel) Selecteer Huisstijl. Voer in Startpagina-URL de URL van uw App Service-app in en selecteer Opslaan.

  9. Selecteer Een API beschikbaar maken en klik op Instellen naast 'Toepassings-id-URI'. Deze waarde identificeert de toepassing op unieke wijze wanneer deze wordt gebruikt als een resource, zodat tokens kunnen worden aangevraagd die toegang verlenen. Deze wordt gebruikt als voorvoegsel voor bereiken die u maakt.

    Voor een app met één tenant kunt u de standaardwaarde gebruiken, in de vorm api://<application-client-id>. U kunt ook een beter leesbare URI opgeven, zoals https://contoso.com/api op basis van een van de geverifieerde domeinen voor uw tenant. Voor een app met meerdere tenants moet u een aangepaste URI opgeven. Zie de aanbevolen procedures voor app-registraties voor meer informatie over geaccepteerde indelingen voor app-id-URI's.

    De waarde wordt automatisch opgeslagen.

  10. Selecteer Een bereik toevoegen.

    1. In Een bereik toevoegen is de toepassings-id-URI de waarde die u in een vorige stap hebt ingesteld. Selecteer Opslaan en doorgaan.
    2. Voer bij Bereiknaamuser_impersonation in.
    3. Voer in de tekstvakken de naam en beschrijving van het toestemmingsbereik in die gebruikers moeten zien op de toestemmingspagina. Voer bijvoorbeeld Access-toepassingsnaam <>in.
    4. Selecteer Bereik toevoegen.
  11. (Optioneel) Als u een clientgeheim wilt maken, selecteert u Certificaten & geheimen>Clientgeheimen>Nieuw clientgeheim. Voer een beschrijving en verloopdatum in en selecteer Toevoegen. Kopieer de waarde van het clientgeheim die wordt weergegeven op de pagina. Deze wordt niet meer weergegeven.

  12. (Optioneel) Als u meerdere antwoord-URL's wilt toevoegen, selecteert u Verificatie.

Azure Active Directory inschakelen in uw App Service-app

  1. Meld u aan bij de Azure Portal en navigeer naar uw app.

  2. Selecteer Verificatie in het menu links. Klik op Id-provider toevoegen.

  3. Selecteer Microsoft in de vervolgkeuzelijst id-provider.

  4. Voor App-registratietype kunt u ervoor kiezen om een bestaande app-registratie in deze map te kiezen , waarmee automatisch de benodigde app-gegevens worden verzameld. Als uw registratie afkomstig is van een andere tenant of als u niet gemachtigd bent om het registratieobject weer te geven, kiest u De details van een bestaande app-registratie opgeven. Voor deze optie moet u de volgende configuratiegegevens invullen:

    Veld Beschrijving
    (Client-)id van de app Gebruik de toepassings-id (client) van de app-registratie.
    Clientgeheim Gebruik het clientgeheim dat u hebt gegenereerd in de app-registratie. Met een clientgeheim wordt hybride stroom gebruikt en retourneert de App Service toegangs- en vernieuwingstokens. Wanneer het clientgeheim niet is ingesteld, wordt impliciete stroom gebruikt en wordt alleen een id-token geretourneerd. Deze tokens worden verzonden door de provider en opgeslagen in het EasyAuth-tokenarchief.
    URL van verlener Gebruik <authentication-endpoint>/<tenant-id>/v2.0en vervang het verificatie-eindpunt> door< het verificatie-eindpuntvoor uw cloudomgeving (bijvoorbeeld 'https://login.microsoftonline.com" voor globale Azure), waarbij ook de tenant-id> wordt vervangen door< de map-id (tenant) waarin de app-registratie is gemaakt. Deze waarde wordt gebruikt om gebruikers om te leiden naar de juiste Azure AD tenant, en om de juiste metagegevens te downloaden om bijvoorbeeld de juiste tokenondertekeningssleutels en claimwaarde voor de tokenverlener te bepalen. Voor toepassingen die gebruikmaken van Azure AD v1, laat u /v2.0 deze weg in de URL.
    Toegestane tokendoelgroep De geconfigureerde toepassings-id (client)-id wordt altijd impliciet beschouwd als een toegestane doelgroep. Als dit een cloud- of server-app is en u verificatietokens wilt accepteren van een client-App Service-app (het verificatietoken kan worden opgehaald in de header X-MS-TOKEN-AAD-ID-TOKEN), voegt u hier de toepassings-id (client)-id van de client-app toe.

    Het clientgeheim wordt opgeslagen als een site-sticky toepassingsinstelling met de naam MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. U kunt deze instelling later bijwerken om Key Vault-verwijzingen te gebruiken als u het geheim wilt beheren in Azure Key Vault.

  5. Als dit de eerste id-provider is die is geconfigureerd voor de toepassing, wordt u ook gevraagd een sectie App Service verificatie-instellingen. Anders kunt u doorgaan met de volgende stap.

    Deze opties bepalen hoe uw toepassing reageert op niet-geverifieerde aanvragen en de standaardselecties leiden alle aanvragen om u aan te melden bij deze nieuwe provider. U kunt dit gedrag nu aanpassen of deze instellingen later aanpassen in het hoofdscherm Verificatie door Bewerken te kiezen naast Verificatie-instellingen. Zie Verificatiestroom voor meer informatie over deze opties.

  6. Klik op Add.

U kunt nu de Microsoft identity platform gebruiken voor verificatie in uw app. De provider wordt weergegeven in het scherm Verificatie . Hier kunt u deze providerconfiguratie bewerken of verwijderen.

Aanvullende validaties (optioneel)

Met de hierboven gedefinieerde stappen kunt u binnenkomende aanvragen voor uw Azure AD tenant verifiëren. Hierdoor kan iedereen binnen de tenant toegang krijgen tot de toepassing. Dit is prima voor veel toepassingen. Sommige toepassingen moeten de toegang echter verder beperken door autorisatiebeslissingen te nemen. Uw toepassingscode is vaak de beste plek om aangepaste autorisatielogica te verwerken. Voor algemene scenario's biedt het platform echter ingebouwde controles die u kunt gebruiken om de toegang te beperken.

In deze sectie wordt beschreven hoe u ingebouwde controles inschakelt met behulp van de V2-API voor App Service-verificatie. Op dit moment is de enige manier om deze ingebouwde controles te configureren via Azure Resource Manager-sjablonen of de REST API.

Binnen het API-object heeft de configuratie van de Azure Active Directory-id-provider een valdation sectie die een defaultAuthorizationPolicy -object kan bevatten, zoals in de volgende structuur:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Eigenschap Beschrijving
defaultAuthorizationPolicy Een groepering van vereisten waaraan moet worden voldaan om toegang te krijgen tot de app. Toegang wordt verleend op basis van een logische AND over elk van de geconfigureerde eigenschappen. Wanneer allowedApplications en allowedPrincipals beide zijn geconfigureerd, moet de binnenkomende aanvraag aan beide vereisten voldoen om te worden geaccepteerd.
allowedApplications Een acceptatielijst met client-id's van tekenreekstoepassingen die de clientresource vertegenwoordigen die de app aanroept. Wanneer deze eigenschap is geconfigureerd als een niet-lege matrix, worden alleen tokens geaccepteerd die zijn verkregen door een toepassing die in de lijst is opgegeven.

Met dit beleid wordt de appid claim of azp van het binnenkomende token geëvalueerd. Dit moet een toegangstoken zijn. Zie de referentie voor Microsoft Identity Platform-claims.
allowedPrincipals Een groep controles die bepalen of de principal die wordt vertegenwoordigd door de binnenkomende aanvraag, toegang heeft tot de app. Tevredenheid van allowedPrincipals is gebaseerd op een logische OR over de geconfigureerde eigenschappen.
identities (onder allowedPrincipals) Een acceptatielijst met tekenreeksobject-id's die gebruikers of toepassingen vertegenwoordigen die toegang hebben. Wanneer deze eigenschap is geconfigureerd als een niet-lege matrix, kan aan de allowedPrincipals vereiste worden voldaan als de gebruiker of toepassing die door de aanvraag wordt vertegenwoordigd, is opgegeven in de lijst.

Dit beleid evalueert de oid claim van het binnenkomende token. Zie de referentie voor Microsoft Identity Platform-claims.

Aanvragen die niet slagen voor deze ingebouwde controles, krijgen een HTTP-antwoord 403 Forbidden .

Client-apps configureren voor toegang tot uw App Service

In de vorige sectie hebt u uw App Service of Azure Function geregistreerd om gebruikers te verifiëren. In deze sectie wordt uitgelegd hoe u systeemeigen client- of daemon-apps kunt registreren, zodat ze namens gebruikers of zichzelf toegang kunnen aanvragen tot API's die door uw App Service worden weergegeven. Het uitvoeren van de stappen in deze sectie is niet vereist als u alleen gebruikers wilt verifiëren.

Systeemeigen clienttoepassing

U kunt systeemeigen clients registreren om namens een aangemelde gebruiker toegang te vragen tot de API's van uw App Service-app.

  1. Selecteer in de Azure PortalActive Directory>App-registraties>Nieuwe registratie.

  2. Voer op de pagina Een toepassing registreren een naam in voor uw app-registratie.

  3. Selecteer in Omleidings-URIde optie Openbare client (mobiel & bureaublad) en typ de URL <app-url>/.auth/login/aad/callback. Bijvoorbeeld https://contoso.azurewebsites.net/.auth/login/aad/callback.

    Notitie

    Voor een Microsoft Store-toepassing gebruikt u in plaats daarvan de pakket-SID als de URI.

  4. Selecteer Maken.

  5. Nadat de app-registratie is gemaakt, kopieert u de waarde van Toepassings-id (client-id).

  6. Selecteer API-machtigingen>Een machtiging toevoegen>Mijn API's.

  7. Selecteer de app-registratie die u eerder hebt gemaakt voor uw App Service-app. Als u de app-registratie niet ziet, controleert u of u het bereik user_impersonation hebt toegevoegd in Een app-registratie maken in Azure AD voor uw App Service-app.

  8. Selecteer onder Gedelegeerde machtigingende optie user_impersonation en selecteer vervolgens Machtigingen toevoegen.

U hebt nu een systeemeigen clienttoepassing geconfigureerd die namens een gebruiker toegang tot uw App Service-app kan aanvragen.

Daemon-clienttoepassing (service-naar-service-aanroepen)

Uw toepassing kan een token verkrijgen om een web-API aan te roepen die wordt gehost in uw App Service of functie-app namens zichzelf (niet namens een gebruiker). Dit scenario is handig voor niet-interactieve daemontoepassingen die taken uitvoeren zonder een aangemelde gebruiker. Er wordt gebruikgemaakt van de standaardtoekenning van OAuth 2.0-clientreferenties .

  1. Selecteer in de Azure PortalActive Directory>App-registraties>Nieuwe registratie.
  2. Voer op de pagina Een toepassing registreren een naam in voor de registratie van uw daemon-app.
  3. Voor een daemontoepassing hebt u geen omleidings-URI nodig, zodat u deze leeg kunt houden.
  4. Selecteer Maken.
  5. Nadat de app-registratie is gemaakt, kopieert u de waarde van Toepassings-id (client-id).
  6. Selecteer Certificaten & geheimen>Nieuw clientgeheim>Toevoegen. Kopieer de waarde van het clientgeheim die wordt weergegeven op de pagina. Deze wordt niet meer weergegeven.

U kunt nu een toegangstoken aanvragen met behulp van de client-id en het clientgeheim door de resource parameter in te stellen op de toepassings-id-URI van de doel-app. Het resulterende toegangstoken kan vervolgens worden gepresenteerd aan de doel-app met behulp van de standaard OAuth 2.0-autorisatieheader en App Service Verificatie/autorisatie valideert en gebruikt het token zoals gewoonlijk om aan te geven dat de aanroeper (een toepassing in dit geval geen gebruiker) is geverifieerd.

Op dit moment kan elke clienttoepassing in uw Azure AD-tenant een toegangstoken aanvragen en verifiëren bij de doel-app. Als u ook autorisatie wilt afdwingen om alleen bepaalde clienttoepassingen toe te staan, moet u een aanvullende configuratie uitvoeren.

  1. Definieer een app-rol in het manifest van de app-registratie die de App Service- of functie-app vertegenwoordigt die u wilt beveiligen.
  2. Selecteer in de app-registratie die de client vertegenwoordigt die moet worden geautoriseerd DE OPTIE API-machtigingen>Een machtiging> toevoegenMijn API's.
  3. Selecteer de app-registratie die u eerder hebt gemaakt. Als u de app-registratie niet ziet, controleert u of u een app-rol hebt toegevoegd.
  4. Selecteer onder Toepassingsmachtigingen de app-rol die u eerder hebt gemaakt en selecteer vervolgens Machtigingen toevoegen.
  5. Zorg ervoor dat u op Beheerderstoestemming verlenen klikt om de clienttoepassing te autoriseren om de machtiging aan te vragen.
  6. Net als in het vorige scenario (voordat er rollen werden toegevoegd), kunt u nu een toegangstoken aanvragen voor hetzelfde doel resourceen bevat het toegangstoken een roles claim met de app-rollen die zijn geautoriseerd voor de clienttoepassing.
  7. In de doel-App Service- of functie-app-code kunt u nu valideren dat de verwachte rollen aanwezig zijn in het token (dit wordt niet uitgevoerd door App Service Verificatie/Autorisatie). Zie Gebruikersclaims openen voor meer informatie.

U hebt nu een daemon-clienttoepassing geconfigureerd die toegang heeft tot uw App Service-app met behulp van een eigen identiteit.

Notitie

De toegangstokens die via EasyAuth aan uw app worden verstrekt, hebben geen bereiken voor andere API's, zoals Graph, zelfs niet als uw toepassing machtigingen heeft voor toegang tot deze API's. Als u deze API's wilt gebruiken, moet u Azure Resource Manager gebruiken om het geretourneerde token te configureren, zodat het kan worden gebruikt voor verificatie bij andere services. Zie Zelfstudie: Toegang tot Microsoft Graph vanuit een beveiligde .NET-app als gebruiker voor meer informatie.

Aanbevolen procedures

Ongeacht de configuratie die u gebruikt voor het instellen van verificatie, zorgen de volgende best practices ervoor dat uw tenant en toepassingen veiliger blijven:

  • Geef elke App Service app zijn eigen machtigingen en toestemming.
  • Configureer elke App Service-app met een eigen registratie.
  • Vermijd het delen van machtigingen tussen omgevingen door afzonderlijke app-registraties te gebruiken voor afzonderlijke implementatiesites. Bij het testen van nieuwe code kan deze procedure helpen voorkomen dat problemen van invloed zijn op de productie-app.

Volgende stappen