Delen via


Overzicht van aangepaste verificatie-extensies

De Microsoft Entra ID-verificatiepijplijn bestaat uit verschillende ingebouwde verificatiegebeurtenissen, zoals de validatie van gebruikersreferenties, beleid voor voorwaardelijke toegang, meervoudige verificatie, selfservice voor wachtwoordherstel en meer.

Met aangepaste verificatie-extensies van Microsoft Entra kunt u verificatiestromen uitbreiden met uw eigen bedrijfslogica op specifieke punten in de verificatiestroom. Een aangepaste verificatie-extensie is in feite een gebeurtenislistener die, wanneer deze wordt geactiveerd, een HTTP-aanroep maakt naar een REST API-eindpunt waar u een werkstroomactie definieert.

U kunt bijvoorbeeld een aangepaste claimprovider gebruiken om externe gebruikersgegevens toe te voegen aan het beveiligingstoken voordat het token wordt uitgegeven. U kunt een werkstroom voor het verzamelen van kenmerken toevoegen om de kenmerken te valideren die een gebruiker invoert tijdens de registratie. Dit artikel bevat een technisch overzicht op hoog niveau van aangepaste verificatie-extensies van Microsoft Entra ID.

De video over het overzicht van aangepaste verificatie-extensies van Microsoft Entra biedt een uitgebreid overzicht van de belangrijkste functies en mogelijkheden van de aangepaste verificatie-extensies.

Overzicht van onderdelen

Er zijn twee onderdelen die u moet configureren: een aangepaste verificatie-extensie in Microsoft Entra en een REST API. De aangepaste verificatie-extensie geeft uw REST API-eindpunt op wanneer de REST API moet worden aangeroepen en de referenties voor het aanroepen van de REST API.

Deze video bevat gedetailleerde instructies voor het configureren van aangepaste verificatie-extensies van Microsoft Entra en biedt aanbevolen procedures en waardevolle tips voor een optimale implementatie.

Aanmeldingsstroom

In het volgende diagram ziet u de aanmeldingsstroom die is geïntegreerd met een aangepaste verificatie-extensie.

Diagram met een token dat wordt uitgebreid met claims van een externe bron.

  1. Een gebruiker probeert zich aan te melden bij een app en wordt omgeleid naar de aanmeldingspagina van Microsoft Entra.
  2. Zodra een gebruiker een bepaalde stap in de verificatie heeft voltooid, wordt een gebeurtenislistener geactiveerd.
  3. Uw aangepaste verificatie-extensie verzendt een HTTP-aanvraag naar uw REST API-eindpunt. De aanvraag bevat informatie over de gebeurtenis, het gebruikersprofiel, sessiegegevens en andere contextinformatie.
  4. De REST API voert een aangepaste werkstroom uit.
  5. De REST API retourneert een HTTP-antwoord op Microsoft Entra-id.
  6. De aangepaste verificatie-extensie van Microsoft Entra verwerkt het antwoord en past de verificatie aan op basis van het gebeurtenistype en de nettolading van het HTTP-antwoord.
  7. Er wordt een token geretourneerd naar de app.

REST API-eindpunten

Wanneer een gebeurtenis wordt geactiveerd, roept Microsoft Entra-id een REST API-eindpunt aan dat u bezit. De REST API moet openbaar toegankelijk zijn. Deze kan worden gehost met behulp van Azure Functions, Azure App Service, Azure Logic Apps of een ander openbaar beschikbaar API-eindpunt.

U hebt de flexibiliteit om elke programmeertaal, framework of oplossing zonder code te gebruiken, zoals Azure Logic Apps om uw REST API te ontwikkelen en te implementeren. Voor een snelle manier om aan de slag te gaan, kunt u overwegen Azure Function te gebruiken. Hiermee kunt u uw code uitvoeren in een serverloze omgeving zonder dat u eerst een virtuele machine (VM) hoeft te maken of een webtoepassing hoeft te publiceren.

Uw REST API moet het volgende verwerken:

Bekijk deze video voor meer informatie over het maken van een REST API-eindpunt voor verificatie-extensies met Azure Logic Apps, zonder code te schrijven. Met Azure Logic App kunnen gebruikers werkstromen bouwen met behulp van een visuele ontwerper. De video bevat informatie over het aanpassen van verificatie-e-mailberichten en is van toepassing op alle typen aangepaste verificatie-extensies, waaronder aangepaste claimproviders.

Nettolading aanvragen

De aanvraag voor de REST API bevat een JSON-nettolading met details over de gebeurtenis, gebruikersprofiel, verificatieaanvraaggegevens en andere contextinformatie. De kenmerken binnen de JSON-nettolading kunnen worden gebruikt om logica door uw API uit te voeren.

In het start-gebeurtenis voor tokenuitgifte kan de aanvraag-payload bijvoorbeeld de unieke identificatie van de gebruiker bevatten, zodat u het gebruikersprofiel kunt ophalen uit uw eigen database. De nettoladinggegevens van de aanvraag moeten het schema volgen zoals is opgegeven in het gebeurtenisdocument.

Gegevens en actietype retourneren

Nadat de web-API de werkstroom met de bedrijfslogica heeft uitgevoerd, moet deze een actietype retourneren waarmee Microsoft Entra wordt geleid in hoe verder te gaan met het verificatieproces.

In het geval van de gebeurtenissen kenmerkverzameling starten en kenmerkverzameling indienen, geeft het door uw web-API geretourneerde actietype aan of het account in de directory kan worden aangemaakt, er een validatiefout moet worden getoond of dat de registratie volledig moet worden geblokkeerd.

Het REST API-antwoord kan gegevens bevatten. De startgebeurtenis voor tokenuitgifte kan bijvoorbeeld een set kenmerken bevatten die kunnen worden toegewezen aan het beveiligingstoken.

Uw REST API beveiligen

Om ervoor te zorgen dat de communicatie tussen de aangepaste verificatie-extensie en uw REST API op de juiste wijze wordt beveiligd, moeten er meerdere beveiligingsmaatregelen worden toegepast.

  1. Wanneer de aangepaste verificatie-extensie uw REST API aanroept, wordt er een HTTP-header met een Bearer-token Authorization verzonden dat is uitgegeven door Microsoft Entra ID.
  2. Het bearer token bevat een appid of azp claim. Controleer of de respectieve claim de 99045fe1-7639-4a75-9d4a-577b6ca3810f waarde bevat. Deze waarde zorgt ervoor dat de Microsoft Entra-id degene is die de REST API aanroept.
    1. Bij V1-toepassingen, valideer de appid claim.
    2. Voor V2 toepassingen, valideer de azp claim.
  3. De doelgroepclaim voor bearer-token aud bevat de ID van de bijbehorende toepassingsregistratie. Uw REST API-eindpunt moet valideren dat het Bearer-token is uitgegeven voor die specifieke doelgroep.
  4. De bearer-tokenverlenerclaim iss bevat de URL van de Microsoft Entra-verlener. Afhankelijk van uw tenantconfiguratie is de URL van de uitgever een van de volgende;
    • Personeel: https://login.microsoftonline.com/{tenantId}/v2.0.
    • Klant: https://{domainName}.ciamlogin.com/{tenantId}/v2.0.

Aangepaste authenticatie-gebeurtenistypen

In deze sectie worden de gebeurtenissen vermeld voor aangepaste verificatie-extensies die beschikbaar zijn voor Microsoft Entra ID-werknemers en externe tenants. Raadpleeg de desbetreffende documentatie voor gedetailleerde informatie over de gebeurtenissen.

Gebeurtenis Personeelstenant Externe huurder
Tokenuitgifte starten
Begin van kenmerkverzameling
Kenmerkverzameling verzenden
Eenmalige wachtwoordcode verzenden

Tokenuitgifte starten

De startgebeurtenis voor tokenuitgifte OnTokenIssuance Start wordt geactiveerd wanneer een token op het punt staat om te worden uitgegeven aan een toepassing. Het is een gebeurtenistype dat is ingesteld binnen een aangepaste claimprovider. De aangepaste claimprovider is een aangepaste verificatie-extensie die een REST API aanroept om claims op te halen uit externe systemen. Een aangepaste claimprovider wijst claims van externe systemen toe aan tokens en kan worden toegewezen aan een of meer toepassingen in uw directory.

Aanbeveling

Probeer het nu

Als u deze functie wilt uitproberen, gaat u naar de demo Woodgrove Boodschappen en start u de use case 'Claims toevoegen aan beveiligingstokens vanuit een REST API'.

Begin van kenmerkverzameling

Start-gebeurtenissen voor kenmerkverzamelingen kunnen worden gebruikt met aangepaste verificatie-extensies om logica toe te voegen voordat kenmerken van een gebruiker worden verzameld. De gebeurtenis OnAttributeCollectionStart vindt plaats aan het begin van de stap voor het verzamelen van kenmerken, voordat de pagina voor het verzamelen van kenmerken wordt weergegeven. Hiermee kunt u acties toevoegen, zoals het vooraf doorvoeren van waarden en het weergeven van een blokkeringsfout.

Aanbeveling

Probeer het nu

Als u deze functie wilt uitproberen, gaat u naar de demo Woodgrove Groceries en start u de gebruikssituatie "Vooraf ingevulde registratiekenmerken".

Attribuutverzameling verzenden

Het verzenden van kenmerkenverzamelingen kan worden gebruikt met aangepaste verificatie-extensies om logica toe te voegen nadat kenmerken van een gebruiker zijn verzameld. Het OnAttributeCollectionSubmit evenement vindt plaats nadat de gebruiker kenmerken invoert en verzendt, waardoor u acties kunt toevoegen zoals het valideren van vermeldingen of het wijzigen van kenmerken.

Aanbeveling

Probeer het nu

Als u deze functie wilt uitproberen, gaat u naar de demo Woodgrove Boodschappen en start u de use-case 'Registratiekenmerken valideren' of 'Voorkomen dat een gebruiker doorgaat met het registratieproces'.

Eenmalige wachtwoordcode verzenden

De gebeurtenis OnOtpSend wordt geactiveerd wanneer een e-mail met een eenmalige wachtwoordcode wordt geactiveerd. Hiermee kunt u een REST API aanroepen om uw eigen e-mailprovider te gebruiken. Deze gebeurtenis kan worden gebruikt om aangepaste e-mailberichten te verzenden naar gebruikers die zich aanmelden met een e-mailadres, zich aanmelden met eenmalige wachtwoordcode (E-mail OTP), hun wachtwoord opnieuw instellen met E-mail OTP of E-mail OTP gebruiken voor meervoudige verificatie (MFA).

Wanneer de gebeurtenis OnOtpSend is geactiveerd, verzendt Microsoft Entra een eenmalige wachtwoordcode naar de opgegeven REST API die u bezit. De REST API gebruikt vervolgens de door u gekozen e-mailprovider, zoals Azure Communication Service of SendGrid, om de eenmalige wachtwoordcode te verzenden met uw aangepaste e-mailsjabloon, van adres en e-mailonderwerp, terwijl ook lokalisatie wordt ondersteund.

Aanbeveling

Probeer het nu

Als u deze functie wilt uitproberen, gaat u naar de Woodgrove Boodschappendemo en start u de use case 'Een aangepaste e-mailprovider gebruiken voor eenmalige code'.