Voorbeeld van EEN API die wordt beveiligd door het Microsoft Identity Consent Framework

Dit artikel kan u, als ontwikkelaar, helpen bij het ontwerpen van uw strategie voor toepassingsmachtigingen om minimale bevoegdheden te bieden. Voordat u doorgaat, raadpleegt u het artikel OVER API-beveiliging voor meer informatie over aanbevolen procedures voor registratie, machtigingen en toegang.

Laten we eens kijken hoe een API die wordt beveiligd door het Microsoft Identity Platform gebruikmaakt van het Microsoft Identity Consent Framework. We gebruiken de Microsoft Graph API als ons voorbeeld omdat dit het meest uitgebreide gebruik maakt van het Microsoft Identity Platform-toestemmingsframework.

Naamconventie voor machtigingsnamen

Het Microsoft Graph-team heeft een naamconventie gemaakt voor machtigingsnamen, zodat het eenvoudiger is om de machtiging te verbinden met de resourcetoegang die door de machtiging wordt ingeschakeld. Microsoft Graph-machtigingsnamen voldoen aan een eenvoudig patroon resource.operation.constraint . De twee primaire bewerkingen zijn Read en ReadWrite (inclusief update en verwijderen).

Het beperkingselement is van invloed op de mate van toegang die uw app heeft in de map. Microsoft Graph ondersteunt deze beperkingen:

• Alle verleent machtigingen voor uw app om de bewerkingen uit te voeren op alle resources van het opgegeven type in een map.
• Gedeeld verleent toestemming voor uw app om de bewerkingen uit te voeren op resources die andere gebruikers hebben gedeeld met de aangemelde gebruiker.
• AppFolder verleent toestemming voor uw app voor het lezen en schrijven van bestanden in een toegewezen map in OneDrive. Deze beperking wordt alleen weergegeven voor het object Bestandenmachtigingen en is alleen geldig voor Microsoft-accounts.
• Als u geen beperking opgeeft, kan uw app alleen de bewerkingen uitvoeren op de resources die de aangemelde gebruiker bezit.

Toegang en bewerkingen voor specifieke bronnen

Laten we eens kijken naar enkele machtigingen of autorisaties voor het gebruikersobject in Microsoft Graph om te zien hoe de Microsoft API-ontwerpers specifieke toegang en bewerkingen voor specifieke resources mogelijk hebben gemaakt.

User.Read en User.ReadWrite bestaan (in tegenstelling tot één machtiging zoals User.Access die bestaat niet) zodat toepassingen het zero trust-principe van minimale bevoegdheden kunnen volgen. Als de ontwikkelaar geen vereiste en code heeft om het profiel van de gebruiker bij te werken, vraagt de app niet om User.ReadWrite. Daarom kan een slechte actor de toepassing niet in gevaar brengen en deze gebruiken om gegevens te wijzigen.

U ziet dat User.Read de toepassing niet alleen toegang verleent tot het gebruikersobject. Elke machtiging vertegenwoordigt een specifiek bewerkingsbereik. Het is belangrijk dat ontwikkelaars en beheerders de beschrijving van de machtiging lezen om precies te zien wat eventuele specifieke machtigingen inschakelen. User.ReadNaast het inschakelen van het lezen van het volledige profiel van de huidige gebruiker, kan de toepassing de basisinformatie van het object Organisaties in Microsoft Graph bekijken.

Laten we eens kijken naar een andere machtiging:

Het bewerkingsbereik van User.ReadBasic.All begint met alles wat User.Read doet. Daarnaast hebt u toegang tot weergavenaam, voor- en familienaam, e-mailadres, foto en open extensies voor andere organisatiegebruikers. Het specifieke bewerkingsbereik stelt toepassingen in staat om een mooie gebruikersinterface voor een personenselector te hebben en is een voorbeeld van hoe API-ontwerpers een machtiging gebruiken om een specifiek bewerkingsbereik mogelijk te maken.

Laten we eens kijken naar een aantal meer machtigingen voor het Microsoft Graph-gebruikersobject:

Net als bij User.Read en User.ReadWrite, User.Read.All en User.ReadWrite.All zijn afzonderlijke machtigingen waarmee een toepassing het principe van zero trust met minimale bevoegdheden kan volgen.

User.Read.All is interessant omdat elke gebruiker in de organisatie deze mogelijkheid heeft (bijvoorbeeld Outlook openen, omhoog en omlaag gaan in een rapportageketen). U kunt als individu het volledige gebruikersprofiel van elke andere gebruiker in uw organisatie zien. De Microsoft Graph API-ontwerpers hebben echter besloten dat alleen beheerders een toepassing dezelfde bewerking mogen laten uitvoeren, omdat User.Read.All dit de organisatiehiërarchie van de tenant omvat. Als een kwaadwillende partij toegang zou hebben tot deze informatie, zou hij of zij een gerichte phishing-aanval kunnen uitvoeren waarbij de phishing-e-mail van iemands manager of diens leidinggevende afkomstig is.

User.ReadWrite.All is een krachtig werkingsgebied. Een toepassing met deze machtiging kan elke gebruiker in de tenant bijwerken of zelfs verwijderen. Als gedelegeerde machtiging kan de app alleen doen wat de huidige gebruiker kan doen wanneer een gebruiker voor de app staat. Gewone gebruikers kunnen andere gebruikers niet bijwerken of verwijderen, ongeacht de machtigingen van de app. Wanneer een tenantbeheerder echter de app gebruikt, kunnen ze deze bewerkingen uitvoeren. Wanneer u besluit deze machtiging te verlenen of te weigeren, evalueert u uw app met een tenantbeheerder in gedachten.

Machtigingen waarvoor beheerderstoestemming is vereist

Gezien de kracht van User.Read.All en User.ReadWrite.All hebben de ontwerpers van de Microsoft Graph API deze machtigingen aangewezen als vereisend beheerdersgoedkeuring. Laten we een beheerderkolom toevoegen aan de tabel met machtigingen om aan te geven wanneer voor de machtiging beheerderstoestemming is vereist:

Zoals wordt weergegeven in het artikel Aanvraagmachtigingen waarvoor beheerderstoestemming is vereist , kunnen tenantbeheerders vereisten overschrijven en alle toepassingsmachtigingen in hun tenant aanwijzen als beheerderstoestemming vereist. Ontwerp uw app om probleemloos te verwerken wanneer u geen token van uw aanvraag ontvangt. Gebrek aan toestemming is een van de vele redenen waarom uw app mogelijk geen token ontvangt.

Volgende stappen 

• Een API aanroepen vanuit een andere API helpt ervoor te zorgen dat Zero Trust wordt gehandhaafd wanneer een API een andere moet aanroepen en draagt bij aan de veilige ontwikkeling van uw applicatie wanneer deze namens een gebruiker werkt.
• U kunt autorisatie verkrijgen voor toegang tot resources om te begrijpen hoe u Zero Trust het beste kunt garanderen bij het verkrijgen van machtigingen voor toegang tot resources voor uw toepassing.
• Tokens aanpassen beschrijft de informatie die u kunt ontvangen in Microsoft Entra-tokens. Hierin wordt uitgelegd hoe u tokens aanpast om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van Zero Trust met minimale bevoegdheden te verhogen.
• Als u groepsclaims en app-rollen in tokens configureert, ziet u hoe u uw apps configureert met app-roldefinities en beveiligingsgroepen toewijst aan app-rollen. Deze methoden helpen om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van Zero Trust met minimale bevoegdheden te verhogen.
• Aanvragen van machtigingen waarvoor beheerderstoestemming is vereist , beschrijft de machtigings- en toestemmingservaring wanneer toepassingsmachtigingen beheerderstoestemming vereisen.
• In deze quickstart: Een web-API beveiligen met het Microsoft Identity Platform, een codevoorbeeld downloaden en uitvoeren dat laat zien hoe u een ASP.NET web-API beveiligt.
• In deze zelfstudie: uw API transformeren en beveiligen in Azure API Management vindt u meer informatie over het configureren van algemeen beleid voor het verbergen van informatie over technologiestacks en oorspronkelijke URL's in de HTTP-antwoordtekst van de API.
• Met best practices voor autorisatie kunt u de beste autorisatie-, machtigings- en toestemmingsmodellen voor uw toepassingen implementeren.