Ontwikkeling van Microsoft Entra-apps

  • 3 minuten

Nu u meer inzicht hebt in de basisprincipes en voordelen van Microsoft Entra ID, moet u bepalen hoe u de mogelijkheden ervan kunt gebruiken om verificatie en autorisatie voor uw toepassing te implementeren. U realiseert zich dat u, om de gegevens van uw klanten te beveiligen, ervoor moet zorgen dat uw implementatie wordt geïntegreerd met postgreSQL-mechanismen voor toegangsbeheer. U hebt besloten om te beginnen de taken te identificeren die betrokken zijn bij het ontwikkelen, inrichten en beheren van Microsoft Entra-toepassingen. U wilt ook bepalen hoe u de noodzaak van toegang tot uw toepassing aan meerdere klanten kunt oplossen.

Als u op Microsoft Entra ID gebaseerde toepassingen wilt implementeren, moet u verschillende toepassingsgerelateerde beheertaken uitvoeren, waaronder het registreren, configureren van de machtigingen en het beheren van de geheimen.

Wat is toepassingsregistratie?

Wanneer een gebruiker in een Microsoft Entra-omgeving werkt, wordt in twee fasen geverifieerd bij een toepassing:

  1. Eerst verifieert Microsoft Entra-id de identiteit van de gebruiker. Na een geslaagde verificatie geeft Microsoft Entra ID tokens die informatie bevatten die de geslaagde verificatie weerspiegelt.
  2. De gebruiker geeft tokens door aan de toepassing. De toepassing valideert de beveiligingstokens van de gebruiker om ervoor te zorgen dat de verificatie is geslaagd.

Als u een dergelijke validatie wilt uitvoeren, moet de toepassing veilig kunnen communiceren met Microsoft Entra-id. Dit vereist op zijn beurt dat de toepassing zelf werkt als een Microsoft Entra-beveiligingsprincipaal. Om dit mogelijk te maken, moet u ervoor zorgen dat de toepassing in een bepaalde vorm wordt weergegeven in dezelfde Microsoft Entra-tenant die het account van de verifiërende gebruiker bevat.

Er zijn twee weergaven van een toepassing in Microsoft Entra-id:

  • Een toepassingsobject dat de eigenschappen van de toepassing definieert.
  • Een service-principal die verificatie- en autorisatiefunctionaliteit biedt en verwijst naar het toepassingsobject.

U kunt toepassingsobjecten rechtstreeks in Azure Portal maken vanaf de blade App-registraties . Voor uw eigen aangepaste toepassingen wordt met deze registratie automatisch de bijbehorende service-principal gemaakt. Daarna kunt u service-principals beheren in Azure Portal vanaf de blade Bedrijfstoepassingen .

Tijdens de registratie van de toepassing kunt u de omleidings-URI (Uniform Resource Identifier) van de toepassing opgeven. De waarde geeft de locatie aan waarnaar de autorisatieserver de gebruiker omleidt nadat de app is geautoriseerd. De autorisatieserver verzendt de code of het token naar de omleidings-URI, dus het is belangrijk dat u de juiste locatie registreert als onderdeel van het app-registratieproces.

Notitie

De omleidings-URI moet beginnen met https, tenzij deze verwijst naar localhost, in dat geval kunt u gebruiken http://localhost. Het is ook hoofdlettergevoelig.

Wat zijn toepassingsmachtigingen?

Toepassingen die zijn geïntegreerd met Microsoft Entra ID volgen een autorisatiemodel waarmee u de machtigingen voor andere geïntegreerde Microsoft Entra-toepassingen en -resources nauwkeurig kunt beheren. Microsoft Entra-id is afhankelijk van het OAuth 2.0-autorisatiemodel om deze machtigingen te implementeren. In OAuth 2.0 worden machtigingen ingedeeld in sets, ook wel bereiken genoemd.

Als ontwikkelaar vraagt u de machtigingen aan die uw toepassing nodig heeft door een machtigingstekenreeks op te geven als onderdeel van de configuratie. Als u bijvoorbeeld de machtigingstekenreeks instelt op 'https://graph.microsoft.com/Calendars.Read", geeft u aan dat de toepassing agenda's van gebruikers in Microsoft Graph moet kunnen lezen. De toepassing moet deze machtigingen krijgen via een toestemming, die moet worden verleend door een Microsoft Entra-gebruiker of een Microsoft Entra-beheerder, afhankelijk van de omvang van deze machtigingen.

Microsoft Entra ID ondersteunt twee typen machtigingen:

  • Gedelegeerde machtigingen worden gebruikt door interactieve apps met een aangemelde gebruiker. Als gevolg hiervan handelt de app namens een aangemelde gebruiker wanneer deze toegang heeft tot de doelresource.
  • Toepassingsmachtigingen worden gebruikt door apps die worden uitgevoerd zonder te vertrouwen op een aangemelde gebruiker, zoals achtergrondservices. Voor deze apps is beheerderstoestemming vereist.

Wat zijn toepassingsgeheimen?

Er zijn twee typen verificatie beschikbaar voor service-principals:

  • Verificatie op basis van wachtwoorden, die afhankelijk is van toepassingsgeheimen die u rechtstreeks in Azure Portal kunt genereren. Bij het genereren van een geheim geeft u de levensduur op.
  • Verificatie op basis van certificaten, die afhankelijk is van certificaten die u uploadt naar Microsoft Entra-id.

Notitie

Als uw toepassing wordt gehost door een Azure-rekenresource, zoals een virtuele Azure-machine (VM), Azure-app Service-web-app of een AKS-cluster, in plaats van service-principals te gebruiken, kunt u overwegen beheerde identiteiten voor uw toepassingsidentiteit te gebruiken. Dit elimineert de noodzaak om wachtwoorden of certificaten voor verificatie te beheren.

Wat zijn verschillende typen toepassingsverificatiescenario's?

De verificatiestroom en de bijbehorende configuratiedetails zijn afhankelijk van het toepassingstype. De algemene categorieën van toepassingstypen zijn:

  • Browser-apps. Dit zijn web-apps waarin tokens worden verkregen door een JavaScript- of TypeScript-app die in de browser wordt uitgevoerd. Deze toepassingen maken vaak gebruik van een framework zoals Angular, React of Vue. MSAL.js is de enige Microsoft Authentication Library die SPA's ondersteunt.
  • Openbare clienttoepassingen. Dit zijn apps die altijd afhankelijk zijn van aangemelde gebruikers om tokens te verkrijgen. Dergelijke apps omvatten desktop- en mobiele apps die web-API's aanroepen namens aangemelde gebruikers.
  • Vertrouwelijke clienttoepassingen. Deze verkrijgen tokens op zichzelf. Apps in deze categorie zijn web-apps die een web-API aanroepen, web-API's die een andere web-API, Linux-daemons en Windows-services aanroepen.

De eerste twee items hierboven verifiëren een gebruiker, terwijl de derde alleen een app of service verifieert tussen de gebruiker en een back-endservice. In dit geval weet de back-endservice niets van de eindgebruiker, maar weet wel welke app deze gebruikt. Denk bijvoorbeeld aan een app die Azure Maps gebruikt als een back-endservice. De maps-service moet weten dat een geautoriseerde toepassing deze aanroept voor de juiste facturering, maar het hoeft niets te weten over de eindgebruiker.

Wat is het verschil tussen toepassingen met één tenant en multitenant Microsoft Entra?

Als ontwikkelaar kunt u ervoor kiezen om uw app te configureren als één tenant of multitenant tijdens de app-registratie:

  • Apps met één tenant zijn alleen beschikbaar in de tenant waarin ze zijn geregistreerd en worden hun thuistenant genoemd.
  • Multitenant-apps zijn beschikbaar voor gebruikers in zowel hun thuistenant als andere Microsoft Entra-tenants.

Als u Azure Portal gebruikt voor app-registratie, geeft u de tenant van de app op door de eigenschap van de doelgroep in te stellen op een van de volgende waarden:

  • Alleen accounts in deze map. Dit resulteert in de configuratie van één tenant. Hierdoor kunt u de toepassing toegang verlenen tot elke beveiligingsprincipaal in uw tenant, inclusief gastaccounts.
  • Accounts in een Microsoft Entra-map. Dit resulteert in een configuratie met meerdere tenants. Hierdoor kunnen gebruikers buiten uw organisatie de toepassing registreren in hun respectieve Microsoft Entra-tenants.
  • Accounts in een Microsoft Entra-adreslijst en persoonlijke Microsoft-accounts (zoals Skype, Xbox, Outlook.com). Dit resulteert ook in een configuratie met meerdere tenants, maar het maakt het mogelijk voor gebruikers met persoonlijke Microsoft-accounts om de app te gebruiken.

Notitie

Er bestaat alleen een toepassingsobject in de basistenant, maar in het geval van de configuratie met meerdere tenants kan er naar worden verwezen door meerdere service-principals in verschillende Microsoft Entra-tenants.