Delen via

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

  • Artikel

Notitie

Vanaf 1 juni 2024 kunnen nieuw gemaakte App Service-apps een unieke standaardhostnaam genereren die gebruikmaakt van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Voorbeeld: myapp-ds27dh7271aah175.westus-01.azurewebsites.net. Bestaande app-namen blijven ongewijzigd.

Zie het blogbericht over het maken van een web-app met een unieke standaardhostnaamvoor meer informatie.

Selecteer een andere verificatieprovider om daarnaartoe te gaan.

In dit artikel leest u hoe u verificatie configureert voor Azure-app Service of Azure Functions, zodat uw app gebruikers aanmeldt met het Microsoft Identity Platform (Microsoft Entra) als verificatieprovider.

Kies een tenant voor uw toepassing en de bijbehorende gebruikers

Voordat uw toepassing gebruikers kan aanmelden, moet u deze registreren in een personeelstenant of een externe tenant. Als u uw app beschikbaar maakt voor werknemers of zakelijke gasten, registreert u uw app in een personeelstenant. Als uw app voor consumenten en zakelijke klanten is, registreert u deze in een externe tenant.

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

  2. Selecteer in het linkermenu van uw app Instellingen>Authenticatie, en selecteer vervolgens Identiteitsprovider toevoegen.

  3. Selecteer Op de pagina Een id-provider toevoegenMicrosoft als id-providerwaarde om Microsoft- en Microsoft Entra-identiteiten aan te melden.

  4. Selecteer onder Kies een tenant voor uw toepassing en de bijbehorende gebruikers:

    • Personeelsconfiguratie (huidige tenant) voor werknemers en zakelijke gasten
    • Externe configuratie voor consumenten en zakelijke klanten

De app-registratie kiezen

De App Service-verificatiefunctie kan automatisch een app-registratie voor u maken. U kunt ook een registratie gebruiken die u of een adreslijstbeheerder afzonderlijk maakt.

Maak automatisch een nieuwe app-registratie, tenzij u een app-registratie afzonderlijk moet maken. U kunt de app-registratie later aanpassen in het Microsoft Entra-beheercentrum .

De volgende situaties zijn de meest voorkomende gevallen voor het gebruik van een bestaande app-registratie:

  • Uw account heeft geen machtigingen voor het maken van app-registraties in uw Microsoft Entra-tenant.
  • U wilt een app-registratie van een andere Microsoft Entra-tenant gebruiken dan de tenant die uw app bevat. Dit is altijd het geval als u externe configuratie hebt geselecteerd bij het kiezen van een tenant.
  • De optie voor het maken van een nieuwe registratie is niet beschikbaar voor overheidsclouds.

Optie 1: Een nieuwe app-registratie maken en gebruiken

  1. Selecteer Nieuwe app-registratie maken.

  2. Voer bij Naam de naam in van de nieuwe app-registratie.

  3. Selecteer de waarde van het ondersteunde accounttype :

    • Huidige huurder - Enkelvoudige huurder. Alleen accounts in deze organisatiemap. Alle gebruikers- en gastaccounts in uw map kunnen gebruikmaken van uw toepassing of API. Gebruik deze optie als uw doelgroep zich binnen uw organisatie bevindt.
    • Elke Microsoft Entra-directory - Multitenant. Accounts in elke organisatiemap. Alle gebruikers met een werk- of schoolaccount van Microsoft kunnen uw toepassing of API gebruiken. Deze accounts omvatten scholen en bedrijven die Gebruikmaken van Office 365. Gebruik deze optie als uw doelgroep zakelijke of educatieve klanten is en multitenancy mogelijk wilt maken.
    • Alle Microsoft Entra-directory's en persoonlijke Microsoft-accounts. Accounts in een organisatiedirectory en persoonlijke Microsoft-accounts (bijvoorbeeld Skype of Xbox). Alle gebruikers met een werk- of schoolaccount of een persoonlijk Microsoft-account kunnen uw toepassing of API gebruiken. Het omvat scholen en bedrijven die Gebruikmaken van Office 365, samen met persoonlijke accounts die worden gebruikt om u aan te melden bij services zoals Xbox en Skype. Gebruik deze optie om gericht te zijn op de breedste set van Microsoft-identiteiten en om multitenancy te activeren.
    • Persoonlijke Microsoft-accounts alleen. Persoonlijke accounts die worden gebruikt om u aan te melden bij services zoals Xbox en Skype. Gebruik deze optie om de breedste set Microsoft-identiteiten te targeten.

U kunt desgewenst de naam van de registratie of de ondersteunde accounttypen wijzigen.

Er wordt een clientgeheim gemaakt als een slot-sticky toepassingsinstelling genaamd MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Als u het geheim in Azure Key Vault wilt beheren, kunt u deze instelling later bijwerken om Key Vault-verwijzingen te gebruiken. U kunt dit ook wijzigen om een identiteit te gebruiken in plaats van een clientgeheim. Ondersteuning voor het gebruik van een identiteit is momenteel beschikbaar als preview-versie.

Optie 2: Gebruik een bestaande registratie die afzonderlijk is gemaakt

Als u een bestaande registratie wilt gebruiken, selecteert u:

  • Kies een bestaande app-registratie in deze map. Selecteer vervolgens een app-registratie in de vervolgkeuzelijst.

  • Geef de details op van een bestaande app-registratie. Geef vervolgens het volgende op:

    • Applicatie (client) ID.

    • Clientgeheim (aanbevolen). Een geheime waarde die door de toepassing wordt gebruikt om de identiteit te bewijzen wanneer er een token wordt aangevraagd. Deze waarde wordt opgeslagen in de configuratie van uw app als een slot-sticky app-instelling met de naam MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Als het clientgeheim niet is ingesteld, gebruiken aanmeldingsbewerkingen van de service de impliciete toekenningsstroom OAuth 2.0, die we niet aanbevelen.

      U kunt de toepassing ook configureren voor het gebruik van een identiteit in plaats van een clientgeheim. Ondersteuning voor het gebruik van een identiteit is momenteel beschikbaar als preview-versie.

    • URL van uitgever. Deze URL heeft de vorm <authentication-endpoint>/<tenant-id>/v2.0. Vervang door <authentication-endpoint> de waarde van het verificatie-eindpunt die specifiek is voor de cloudomgeving. Een personeelstenant in globale Azure zou bijvoorbeeld https://sts.windows.net als zijn verificatie-eindpunt gebruiken.

Als u handmatig een app-registratie in een werknemersomgeving moet maken, raadpleegt u Een toepassing registreren bij het Microsoft Identity Platform. Wanneer u het registratieproces doorloopt, moet u de waarden voor de toepassings-id (client) en clientgeheim noteren.

Tijdens het registratieproces, in de sectie Omleidings-URI's, selecteer Web voor het platform en geef <app-url>/.auth/login/aad/callback in. Voer bijvoorbeeld https://contoso.azurewebsites.net/.auth/login/aad/callback in.

Wijzig nu de app-registratie:

  1. Selecteer in het linkerdeelvenster Een API beschikbaar maken>Toevoegen>Opslaan. Deze waarde identificeert de toepassing uniek wanneer deze wordt gebruikt als een resource, waarmee tokens die toegang verlenen, kunnen worden aangevraagd. De waarde is een voorvoegsel voor scopen die u aanmaakt.

    Voor een app met één tenant kunt u de standaardwaarde gebruiken, die zich in het formulier bevindt 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 multitenant-app moet u een aangepaste URI opgeven. Zie de aanbevolen beveiligingsprocedures voor toepassingseigenschappen in Microsoft Entra ID voor meer informatie over geaccepteerde indelingen voor app-id-URI's.

  2. Selecteer Een bereik toevoegen en vervolgens:

    1. In de bereiknaam voert u user_impersonation in.
    2. In Wie kan toestemming geven, selecteert u Beheerders en gebruikers als u wilt toestaan dat gebruikers toestemming geven voor dit bereik.
    3. Voer de naam van het toestemmingsbereik in. Voer een beschrijving in die gebruikers moeten zien op de toestemmingspagina. Voer bijvoorbeeld de naam van deAccess-toepassing in.
    4. Selecteer Bereik toevoegen.

  3. (Aanbevolen) Maak een clientbevestiging voor de app. Het cliëntgeheim aanmaken:

    1. Selecteer in het linkerdeelvenster Certificaten & GeheimenClientgeheimenNieuw clientgeheim.
    2. Voer een beschrijving en vervaldatum in en selecteer Vervolgens Toevoegen.
    3. Kopieer in het veld Waarde de waarde van het clientgeheim. Nadat u van deze pagina bent verwijderd, wordt deze niet meer weergegeven.

    U kunt de toepassing ook configureren voor het gebruik van een identiteit in plaats van een clientgeheim. Ondersteuning voor het gebruik van een identiteit is momenteel beschikbaar als preview-versie.

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

Aanvullende controles configureren

Aanvullende controles bepalen welke aanvragen toegang hebben tot uw toepassing. U kunt dit gedrag nu aanpassen of u kunt deze instellingen later aanpassen op de hoofdpagina voor verificatie door Bewerken naast verificatie-instellingen te selecteren.

Voor de vereiste clienttoepassing, kies of u het volgende wilt doen:

  • Alleen aanvragen van deze toepassing zelf toestaan.
  • Aanvragen van specifieke clienttoepassingen toestaan.
  • Aanvragen van een toepassing toestaan (niet aanbevolen).

Kies voor identiteitsvereiste of u het volgende wilt doen:

  • Aanvragen van elke identiteit toestaan.
  • Aanvragen van specifieke identiteiten toestaan.

Voor tenantvereisten, kies of u het volgende wilt doen:

  • Alleen verzoeken van de uitgevende tenant toestaan.
  • Aanvragen van specifieke tenants toestaan.
  • Gebruik standaardbeperkingen op basis van de verlener.

Uw app moet mogelijk nog andere autorisatiebeslissingen nemen in code. Zie Een ingebouwd autorisatiebeleid gebruiken verderop in dit artikel voor meer informatie.

Verificatie-instellingen configureren

Verificatie-instellingen bepalen hoe uw toepassing reageert op niet-geverifieerde aanvragen. De standaardselecties sturen alle verzoeken door om in te loggen bij deze nieuwe provider. U kunt dit gedrag nu aanpassen of u kunt deze instellingen later aanpassen op de hoofdpagina voor verificatie door Bewerken naast verificatie-instellingen te selecteren. Zie Verificatiestroom voor meer informatie.

Als u de toegang wilt beperken, moet u beslissen of u het volgende wilt doen:

  • Authenticatie vereist.
  • Niet-geverifieerde toegang toestaan.

Voor niet-geverifieerde aanvragen kiest u foutopties:

  • HTTP 302 Found redirect: aanbevolen voor websites
  • HTTP 401 Unauthorized: aanbevolen voor API's
  • HTTP 403 Forbidden
  • HTTP 404 Not found

Selecteer Tokenwinkel (aanbevolen). In het tokenarchief worden tokens voor uw toepassing verzameld, opgeslagen en vernieuwd. U kunt dit gedrag later uitschakelen als uw app geen tokens nodig heeft of als u de prestaties wilt optimaliseren.

De id-provider toevoegen

Als u de configuratie van werknemers hebt geselecteerd, kunt u Volgende selecteren: Machtigingen en eventuele Microsoft Graph-machtigingen toevoegen die de toepassing nodig heeft. Deze machtigingen worden toegevoegd aan de app-registratie, maar u kunt ze later ook wijzigen. Als u externe configuratie hebt geselecteerd, kunt u later Microsoft Graph-machtigingen toevoegen.

  • Selecteer Toevoegen.

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

Zie App-verificatie toevoegen aan uw web-app voor een voorbeeld van het configureren van Microsoft Entra-aanmelding voor een web-app die toegang heeft tot Azure Storage en Microsoft Graph.

Aanvragen autoriseren

Standaard verwerkt App Service-verificatie alleen verificatie. Het bepaalt of de beller is wie ze zeggen dat ze zijn. Autorisatie, het bepalen of die beller toegang moet hebben tot een bepaalde resource, is een stap verder dan verificatie. Zie De basisprincipes van autorisatie voor meer informatie.

Uw app kan autorisatiebeslissingen nemen in code. App Service-verificatie biedt een aantal ingebouwde controles, wat kan helpen, maar ze alleen zijn mogelijk niet voldoende om de autorisatiebehoeften van uw app te dekken. In de volgende secties worden deze mogelijkheden besproken.

Tip

Multitenant-toepassingen moeten de uitgever en tenant-ID van de aanvraag valideren als onderdeel van dit proces om er zeker van te zijn dat de waarden toegestaan zijn. Wanneer App Service-verificatie is geconfigureerd voor een scenario met meerdere tenants, wordt niet gevalideerd van welke tenant de aanvraag afkomstig is. Een app moet mogelijk worden beperkt tot specifieke tenants, op basis van of de organisatie zich heeft geregistreerd voor de service (bijvoorbeeld). Zie Uw code bijwerken om meerdere uitgeverswaarden te verwerken.

Validaties uitvoeren vanuit toepassingscode

Wanneer u autorisatiecontroles uitvoert in uw app-code, kunt u de claimgegevens gebruiken die App Service-verificatie beschikbaar maakt. Zie Access-gebruikersclaims in app-code voor meer informatie.

De geïnjecteerde x-ms-client-principal header bevat een Base64-gecodeerd JSON-object met de claims die over aanroeper zijn gesteld. Deze claims doorlopen standaard een claimtoewijzing, zodat de claimnamen mogelijk niet altijd overeenkomen met wat u in het token zou zien. De claim wordt bijvoorbeeld gemapt naar http://schemas.microsoft.com/identity/claims/tenantid in plaats daarvan.

U kunt ook rechtstreeks met het onderliggende toegangstoken werken vanuit de geïnjecteerde x-ms-token-aad-access-token header.

Een ingebouwd autorisatiebeleid gebruiken

De gemaakte app-registratie verifieert binnenkomende aanvragen voor uw Microsoft Entra-tenant. Standaard kan iedereen binnen de tenant toegang krijgen tot de toepassing. Deze aanpak is prima voor veel toepassingen. Sommige toepassingen moeten de toegang verder beperken door autorisatiebeslissingen te nemen.

Uw toepassingscode is vaak de beste plaats om aangepaste autorisatielogica te verwerken. Voor veelvoorkomende scenario's biedt het Microsoft Identity Platform echter ingebouwde controles die u kunt gebruiken om de toegang te beperken.

In deze sectie wordt beschreven hoe u ingebouwde controles kunt inschakelen met behulp van de App Service-verificatie-V2-API. Momenteel is de enige manier om deze ingebouwde controles te configureren met behulp van Azure Resource Manager-sjablonen of de REST API.

Binnen het API-object heeft de configuratie van de Microsoft Entra-id-provider een sectie die een validationdefaultAuthorizationPolicy object kan bevatten, zoals wordt weergegeven in de volgende structuur:

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

Met dit beleid wordt de appid of azp claim van het binnenkomende token geëvalueerd. Dit moet een toegangstoken zijn. Zie Payload claims.
allowedPrincipals Een groep controles die bepalen of de principal die de binnenkomende aanvraag vertegenwoordigt, toegang heeft tot de app. Tevredenheid van allowedPrincipals is gebaseerd op een logische OR over de geconfigureerde eigenschappen ervan.
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 de aanvraag vertegenwoordigt, is gespecificeerd in de lijst. Er geldt een limiet van 500 tekens (totaal) in de lijst met identiteiten.

Met dit beleid wordt de oid claim van het binnenkomende token geëvalueerd. Zie ladingaanspraken.

U kunt ook enkele controles configureren via een toepassingsinstelling, ongeacht de API-versie die u gebruikt. U kunt de WEBSITE_AUTH_AAD_ALLOWED_TENANTS toepassingsinstelling configureren met een door komma's gescheiden lijst met maximaal 10 tenant-id's, aaaabbbb-0000-cccc-1111-dddd2222eeeebijvoorbeeld. Deze instelling kan vereisen dat het binnenkomende token afkomstig is van een van de opgegeven tenants, zoals opgegeven door de tid claim.

U kunt de WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL toepassingsinstelling configureren op true of 1, zodat het binnenkomende token een oid claim moet bevatten. Als u deze instelling hebt geconfigureerd allowedPrincipals.identities, wordt deze instelling genegeerd en behandeld als waar omdat de oid claim wordt gecontroleerd op basis van deze opgegeven lijst met identiteiten.

Aanvragen die mislukken bij deze ingebouwde controles krijgen een HTTP-antwoord 403 Forbidden .

Een beheerde identiteit gebruiken in plaats van een geheim (preview)

In plaats van een clientgeheim te configureren voor uw app-registratie, kunt u een toepassing configureren om een beheerde identiteit (preview) te vertrouwen. Als u een identiteit gebruikt in plaats van een geheim, hoeft u geen geheim te beheren. U hebt geen geheime verloop gebeurtenissen om af te handelen en u hebt niet hetzelfde risiconiveau dat is gekoppeld aan het mogelijk vrijgeven of lekken van dat geheim.

Met de identiteit kunt u een federatieve identiteitsreferentie maken, die kan worden gebruikt in plaats van een clientgeheim als clientverklaring. Deze benadering is alleen beschikbaar voor personeelsconfiguraties. De ingebouwde verificatiefunctie ondersteunt momenteel federatieve identiteitsgegevens als preview.

U kunt de stappen in deze sectie gebruiken om uw App Service- of Azure Functions-resource te configureren om dit patroon te gebruiken. In de volgende stappen wordt ervan uitgegaan dat u al een app-registratie hebt ingesteld met behulp van een van de ondersteunde methoden en dat u al een geheim hebt gedefinieerd.

  1. Maak een door de gebruiker toegewezen beheerde identiteitresource volgens deze instructies.

  2. Wijs die identiteit toe aan uw App Service- of Azure Functions-resource.

    Belangrijk

    De door de gebruiker toegewezen beheerde identiteit die u maakt, mag alleen worden toegewezen aan de App Service- of Azure Functions-toepassing via deze registratie. Als u de identiteit toewijst aan een andere resource, geeft u die resource onnodige toegang tot uw app-registratie.

  3. Noteer de object-id en client-id-waarden van de beheerde identiteit. U hebt de object-id nodig om in de volgende stap een federatieve identiteitsreferentie te maken. In een latere stap gebruikt u de client-id van de beheerde identiteit.

  4. Volg de instructies voor Microsoft Entra ID om een federatieve identiteitsreferentie voor een bestaande toepassing te configureren. Deze instructies bevatten ook secties voor het bijwerken van toepassingscode, die u kunt overslaan.

  5. Voeg een nieuwe toepassingsinstelling toe met de naam OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Stel de waarde ervan in op de client-id-waarde van de beheerde identiteit die u in een vorige stap hebt verkregen. Gebruik de client-id van uw app-registratie niet. Zorg ervoor dat deze toepassingsinstelling als slot-sticky gemarkeerd is.

  6. Stel in de ingebouwde verificatie-instellingen voor uw app-resource de naam van de clientgeheiminstelling in op OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Ga als volgt te werk om deze wijziging aan te brengen met behulp van Azure Portal:

    1. Ga terug naar uw App Service- of Azure Functions-resource en selecteer het tabblad Verificatie .
    2. Selecteer in de sectie Id-provider voor het Microsoft-item het pictogram in de kolom Bewerken .
    3. Open in het dialoogvenster Id-provider bewerken de vervolgkeuzelijst voor de naam van de instelling clientgeheim en selecteer OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
    4. Selecteer Opslaan.

    Ga als volgt te werk om deze wijziging aan te brengen met behulp van de REST API:

    • Stel de eigenschap clientSecretSettingName in op OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. U vindt deze eigenschap onder propertiesazureActiveDirectory>registrationidentityProviders>>.

  7. Controleer of de toepassing werkt zoals verwacht. U moet een nieuwe aanmeldingsactie kunnen uitvoeren.

Wanneer u tevreden bent met het gedrag met behulp van een beheerde identiteit, verwijdert u het bestaande geheim:

  1. Zorg ervoor dat uw app-code geen afhankelijkheid heeft van de toepassingsinstelling. Als dit het geval is, volgt u de instructies om uw toepassingscode bij te werken om een toegangstoken aan te vragen.

  2. Verwijder de toepassingsinstelling die eerder uw geheime informatie bevatte. De naam van deze toepassingsinstelling is de naamwaarde van de vorige clientgeheiminstelling , voordat u deze instelt op OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Meld u aan bij het Microsoft Entra-beheercentrum met behulp van de tenant die uw app-registratie bevat. Ga opnieuw naar de app-registratie.

  4. Selecteer onder Certificaten en geheimenclientgeheimen en verwijder het clientgeheim.

Uw app is nu geconfigureerd voor het gebruik van Microsoft Entra ID-verificatie zonder geheimen.

Client-apps configureren voor toegang tot App Service

In eerdere secties hebt u uw App Service- of Azure Functions-app geregistreerd om gebruikers te verifiëren. In de volgende secties wordt uitgelegd hoe u systeemeigen clients of daemon-apps registreert in Microsoft Entra. Deze clients of apps kunnen toegang aanvragen tot API's die door App Service worden weergegeven namens gebruikers of zichzelf, zoals in een architectuur met N-lagen. Als u alleen gebruikers wilt verifiëren, zijn de stappen in de volgende secties niet vereist.

Systeemeigen client

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

  1. Selecteer Microsoft Entra ID in het menu van Azure Portal.

  2. In het linkerdeelvenster, selecteer beheren>App-registraties. Selecteer vervolgens Nieuwe registratie.

  3. Voer in het deelvenster Een toepassing registreren bij Naam een naam in voor uw app-registratie.

  4. Selecteer in Redirect URI de optie openbare client/systeemeigen (mobiel en desktop) en voer de URL <app-url>/.auth/login/aad/callback in. Voer bijvoorbeeld https://contoso.azurewebsites.net/.auth/login/aad/callback in.

  5. Selecteer Registreren.

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

    Notitie

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

  7. Selecteer Beheren>API-machtigingen in het linkerdeelvenster. Selecteer vervolgens Een machtiging toevoegen>Mijn API's.

  8. Selecteer de app-registratie die u eerder hebt gemaakt voor uw App Service-app. Als u de app-registratie niet ziet, zorg ervoor dat het user_impersonation scope is toegevoegd in de app-registratie.

  9. Onder Gedelegeerde Machtigingen selecteer user_impersonation en selecteer vervolgens machtigingen toevoegen.

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

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

In een N-tier-architectuur kan uw clienttoepassing een token verkrijgen om een App Service- of Azure Functions-app aan te roepen namens de client-app zelf, niet namens een gebruiker. Dit scenario is handig voor niet-interactieve daemon-toepassingen die taken uitvoeren zonder een aangemelde gebruiker. Het maakt gebruik van de standaard OAuth 2.0 clientreferenties-toekenning. Zie Microsoft Identity Platform en de OAuth 2.0-clientreferentiestroom voor meer informatie.

  1. Selecteer Microsoft Entra ID in het menu van Azure Portal.

  2. Selecteer in het linkerdeelvenster Beheren>App-registraties. Selecteer vervolgens Nieuwe registratie.

  3. Voer in het deelvenster Een toepassing registreren bij Naam een naam in voor uw app-registratie.

  4. Voor een daemon-toepassing hebt u geen omleidings-URI nodig, zodat u het vak Omleidings-URI leeg kunt houden.

  5. Selecteer Registreren.

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

  7. SelecteerCertificaten en geheimen beheren> in het linkerdeelvenster. Vervolgens Clientgeheimen>Nieuw clientgeheim selecteren.

  8. Voer een beschrijving en vervaldatum in en selecteer Vervolgens Toevoegen.

  9. Kopieer in het veld Waarde de waarde van het clientgeheim. Nadat u van deze pagina bent verwijderd, wordt deze niet meer weergegeven.

U kunt nu een toegangstoken aanvragen met behulp van de client-id en het clientgeheim. Stel de resource parameter in op de URI-waarde van de toepassings-id van de doel-app. Het resulterende toegangstoken kan vervolgens worden gepresenteerd aan de doel-app via de standaard OAuth 2.0-autorisatieheader. App Service-verificatie valideert en gebruikt het token om aan te geven dat de beller is geverifieerd. In dit geval is de aanroeper een toepassing, niet een gebruiker.

Met deze methode kan elke clienttoepassing in uw Microsoft Entra-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 extra configuratie uitvoeren.

  1. Definieer een app-rol in het manifest van de app-registratie die de App Service- of Azure Functions-app vertegenwoordigt die u wilt beveiligen.

  2. Selecteer in de app-registratie die de te autoriseren client vertegenwoordigt, API-machtigingen>Een machtiging toevoegen>Mijn 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. Selecteer vervolgens Machtigingen toevoegen.

  5. Selecteer Beheerderstoestemming verlenen om de clienttoepassing toestemming te geven om de machtiging aan te vragen.

    Net als bij het vorige scenario (voordat u rollen hebt toegevoegd), kunt u nu een toegangstoken aanvragen voor dezelfde doelresource. Het toegangstoken bevat een roles claim die de app-rollen bevat die zijn geautoriseerd voor de clienttoepassing.

In de app-code van de doel-App Service of Azure Functions kunt u nu valideren dat het token de verwachte rollen heeft. App Service-verificatie voert deze validatie niet uit. Zie Access-gebruikersclaims in app-code voor meer informatie.

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

Beste praktijken

Ongeacht de configuratie die u gebruikt om verificatie in te stellen, houden de volgende aanbevolen procedures uw tenant en toepassingen veiliger:

  • Configureer elke App Service-app met een eigen app-registratie in Microsoft Entra.
  • Geef elke App Service-app zijn eigen machtigingen en toestemming.
  • Vermijd het delen van machtigingen tussen omgevingen. Gebruik afzonderlijke app-registraties voor afzonderlijke implementatieslots. Wanneer u nieuwe code test, kan deze procedure helpen voorkomen dat problemen van invloed zijn op de productie-app.

Migreren naar Microsoft Graph

Sommige oudere apps kunnen worden ingesteld met een afhankelijkheid van Azure AD Graph, die is afgeschaft en gepland voor volledige buitengebruikstelling. Uw app-code kan bijvoorbeeld Azure AD Graph aanroepen om het groepslidmaatschap te controleren als onderdeel van een autorisatiefilter in een middleware-pijplijn. Apps moeten worden verplaatst naar Microsoft Graph. Zie Uw apps migreren van Azure AD Graph naar Microsoft Graph voor meer informatie.

Tijdens deze migratie moet u mogelijk enkele wijzigingen aanbrengen in uw configuratie van App Service-verificatie. Nadat u Microsoft Graph-machtigingen hebt toegevoegd aan uw app-registratie, kunt u het volgende doen:

  • Werk de URL-waarde van de uitgever bij om het /v2.0 achtervoegsel op te nemen als dit nog niet het geval is.

  • Verwijder aanvragen voor Azure AD Graph-machtigingen uit uw aanmeldingsconfiguratie. Welke eigenschappen u wilt wijzigen, is afhankelijk van de versie van de beheer-API die u gebruikt:

    • Als u de V1-API (/authsettings) gebruikt, bevindt deze instelling zich in de additionalLoginParams matrix.
    • Als u de V2-API (/authsettingsV2) gebruikt, bevindt deze instelling zich in de loginParameters matrix.

    U moet bijvoorbeeld een verwijzing naar https://graph.windows.netverwijderen. Deze wijziging omvat de resource parameter die het /v2.0 eindpunt niet ondersteunt. Het omvat ook scopen die u specifiek aanvraagt van Azure AD Graph.

    U moet ook de configuratie bijwerken om de nieuwe Microsoft Graph-machtigingen aan te vragen die u hebt ingesteld voor de registratie van de toepassing. In veel gevallen kunt u het standaardbereik gebruiken om deze installatie te vereenvoudigen. Voeg hiervoor een nieuwe aanmeldingsparameter toe: scope=openid profile email https://graph.microsoft.com/.default.

Wanneer App Service-verificatie zich probeert aan te melden, worden met deze wijzigingen geen machtigingen meer aangevraagd voor Azure AD Graph. In plaats daarvan krijgt het een token voor Microsoft Graph. Elk gebruik van dat token vanuit uw toepassingscode moet ook worden bijgewerkt, zoals beschreven in Uw apps migreren van Azure AD Graph naar Microsoft Graph.

Verwante inhoud