Overzicht van aangepast azure AD B2C-beleid

Belangrijk

Vanaf 1 mei 2025 is Azure AD B2C niet meer beschikbaar voor nieuwe klanten. Meer informatie vindt u in onze veelgestelde vragen.

Aangepaste beleidsregels zijn configuratiebestanden die het gedrag van uw Azure AD B2C-tenant (Azure Active Directory B2C) definiëren. Hoewel gebruikersstromen vooraf zijn gedefinieerd in de Azure AD B2C-portal voor de meest voorkomende identiteitstaken, kan een identiteitsontwikkelaar aangepaste beleidsregels bewerken om veel verschillende taken uit te voeren.

Een aangepast beleid is volledig configureerbaar en beleidsgestuurd. Een aangepast beleid organiseert een vertrouwensrelatie tussen entiteiten in standaardprotocollen. OpenID Connect, OAuth, SAML en enkele niet-standaardinstellingen, bijvoorbeeld op REST API gebaseerde systeem-naar-systeemclaimuitwisselingen. Het framework maakt gebruiksvriendelijke, witgelabelde ervaringen.

Een aangepast beleid wordt weergegeven als een of meer XML-bestanden die naar elkaar verwijzen in een hiërarchische keten. De XML-elementen definiëren de bouwstenen, de interactie met de gebruiker en andere partijen en de bedrijfslogica.

Aangepast starterspakket voor beleid

Azure AD B2C-aangepast beleidsstarterpack wordt geleverd met verschillende vooraf gedefinieerde beleidsregels om snel aan de slag te gaan. Elk van deze starterspakketten bevat het kleinste aantal technische profielen en gebruikerstrajecten dat nodig is om de beschreven scenario's te bereiken:

• LocalAccounts : hiermee schakelt u alleen het gebruik van lokale accounts in.
• SocialAccounts : hiermee wordt alleen het gebruik van sociale (of federatieve) accounts ingeschakeld.
• SocialAndLocalAccounts : maakt het gebruik van zowel lokale als sociale accounts mogelijk. De meeste van onze voorbeelden verwijzen naar dit beleid.
• SocialAndLocalAccountsWithMFA : maakt sociale, lokale en meervoudige verificatieopties mogelijk.

In de GitHub-opslagplaats met Azure AD B2C-voorbeelden vindt u voorbeelden voor verschillende verbeterde aangepaste CIAM-gebruikerstrajecten en -scenario's van Azure AD B2C. Bijvoorbeeld verbeteringen van het lokale accountbeleid, verbeteringen van het sociaal-accountbeleid, MFA-verbeteringen, verbeteringen van de gebruikersinterface, algemene verbeteringen, app-migratie, gebruikersmigratie, voorwaardelijke toegang, webtest en CI/CD.

De basisbeginselen begrijpen

Aanspraken

Een claim biedt tijdelijke opslag van gegevens tijdens het uitvoeren van een Azure AD B2C-beleid. Claims zijn meer vergelijkbaar met variabelen in een programmeertaal. Het kan informatie over de gebruiker opslaan, zoals voornaam, familienaam of een andere claim die is verkregen van de gebruiker of andere systemen (claims uitwisselingen). Het claimschema is de plaats waar u uw claims declareert.

Wanneer het beleid wordt uitgevoerd, verzendt en ontvangt Azure AD B2C claims naar en van interne en externe partijen en verzendt vervolgens een subset van deze claims naar uw relying party-toepassing als onderdeel van het token. Claims worden op deze manieren gebruikt:

• Een claim wordt opgeslagen, gelezen of bijgewerkt op basis van het gebruikersobject van de directory.
• Een claim wordt ontvangen van een externe id-provider.
• Claims worden verzonden of ontvangen met behulp van een aangepaste REST API-service.
• Gegevens worden verzameld als claims van de gebruiker tijdens het registratie- of profielbewerkingsproces.

Uw claims manipuleren

De claimtransformaties zijn vooraf gedefinieerde functies die kunnen worden gebruikt om een bepaalde claim te converteren naar een andere, een claim te evalueren of een claimwaarde in te stellen. U kunt bijvoorbeeld een item toevoegen aan een tekenreeksverzameling, het hoofdlettergebruik van een tekenreeks wijzigen of een datum- en tijdclaim evalueren. Een claimtransformatie geeft een transformatiemethode op, die ook vooraf is gedefinieerd.

Uw gebruikersinterface aanpassen en lokaliseren

Als u gegevens van uw gebruikers wilt verzamelen door een pagina in hun webbrowser te presenteren, gebruikt u het zelfbewuste technische profiel. U kunt uw zelfbeclaimde technische profiel bewerken om claims toe te voegen en gebruikersinvoer aan te passen.

Als u de gebruikersinterface voor uw zelfbewuste technische profiel wilt aanpassen, geeft u een URL op in het inhoudsdefinitieelement met aangepaste HTML-inhoud. In het zelfverklaarde technische profiel wijst u naar deze inhoudsdefinitie-ID.

Gebruik het lokalisatieelement om taalspecifieke tekenreeksen aan te passen. Een inhoudsdefinitie kan een lokalisatiereferentie bevatten waarmee een lijst met gelokaliseerde resources wordt opgegeven die moeten worden geladen. Azure AD B2C voegt elementen van de gebruikersinterface samen met de HTML-inhoud die vanuit uw URL wordt geladen en geeft de pagina vervolgens weer aan de gebruiker.

Overzicht van beleid voor vertrouwende partijen

Een relying party-toepassing, die in het SAML-protocol bekend staat als een serviceprovider, roept het relying party-beleid aan om een specifiek gebruikerstraject uit te voeren. Het relying party-beleid specificeert de gebruikersreis die moet worden uitgevoerd en de lijst van claims die het token bevat.

Alle relying party-toepassingen die hetzelfde beleid gebruiken, ontvangen dezelfde tokenclaims en de gebruiker doorloopt hetzelfde gebruikerstraject.

Gebruikersreizen

Met gebruikerstrajecten kunt u de bedrijfslogica definiëren met het pad dat de gebruiker volgt om toegang te krijgen tot uw toepassing. De gebruiker wordt door het gebruikerstraject genomen om de claims op te halen die aan uw toepassing moeten worden gepresenteerd. Een gebruikerstraject is opgebouwd uit een reeks orkestratiestappen. Een gebruiker moet de laatste stap bereiken om een token te verkrijgen.

In de volgende instructies wordt beschreven hoe u orkestratiestappen kunt toevoegen aan het starterpack-beleid voor sociale en lokale accounts. Hier volgt een voorbeeld van een REST API-aanroep die is toegevoegd.

Orchestatiestappen

De orkestratiestap verwijst naar een methode die zijn beoogde doel of functionaliteit implementeert. Deze methode wordt een technisch profiel genoemd. Wanneer uw gebruikerstraject moet vertakken om de bedrijfslogica beter weer te geven, verwijst de indelingsstap naar het subtraject. Een subtraject heeft een eigen set orkestratiestappen.

Een gebruiker moet de laatste indelingsstap in het gebruikerstraject bereiken om een token te verkrijgen. Maar gebruikers hoeven mogelijk niet alle orkestratiestappen te doorlopen. Orkestratiestappen kunnen op voorwaardelijke basis worden uitgevoerd op basis van voorwaarden die zijn gedefinieerd in de orkestratiestap.

Nadat een orkestratiestap is voltooid, slaat Azure AD B2C de resulterende claims op in de claims bag. De claims in de claimtas kunnen worden gebruikt door verdere indelingsstappen in het gebruikerstraject.

In het volgende diagram ziet u hoe de indelingsstappen van het gebruikerstraject toegang hebben tot de claimtas.

Technisch profiel

Een technisch profiel biedt een interface om te communiceren met verschillende soorten partijen. Een gebruikerstraject combineert het aanroepen van technische profielen via indelingsstappen om uw bedrijfslogica te definiëren.

Alle typen technische profielen delen hetzelfde concept. U verzendt invoerclaims, voert claimtransformatie uit en communiceert met de geconfigureerde partij. Nadat het proces is voltooid, retourneert het technische profiel de uitvoerclaims naar claims bag. Zie het overzicht van technische profielen voor meer informatie.

Technisch validatieprofiel

Wanneer een gebruiker communiceert met de gebruikersinterface, kunt u de verzamelde gegevens valideren. Als u met de gebruiker wilt communiceren, moet een zelfbeweert technisch profiel worden gebruikt.

Om de gebruikersinvoer te valideren, wordt een technisch validatieprofiel aangeroepen vanuit het zelfverklaarde technische profiel. Een validatie-technisch profiel is een methode om een niet-interactief technisch profiel aan te roepen. In dit geval kan het technische profiel uitvoerclaims of een foutbericht retourneren. Het foutbericht wordt weergegeven aan de gebruiker op het scherm, zodat de gebruiker het opnieuw kan proberen.

In het volgende diagram ziet u hoe Azure AD B2C gebruikmaakt van een technisch validatieprofiel om de gebruikersreferenties te valideren.

Erfelijkheidsmodel

Elk starterspakket bevat de volgende bestanden:

• Een basisbestand met de meeste definities. Als u wilt helpen bij het oplossen van problemen en langetermijnonderhoud van uw beleid, probeert u het aantal wijzigingen dat u aanbrengt in dit bestand te minimaliseren.
• Een lokalisatiebestand met de lokalisatietekenreeksen. Dit beleidsbestand is afgeleid van het basisbestand. Gebruik dit bestand om verschillende talen aan te passen aan de behoeften van uw klant.
• Een extensiebestand met de unieke configuratiewijzigingen voor uw tenant. Dit beleidsbestand is afgeleid van het lokalisatiebestand. Gebruik dit bestand om nieuwe functionaliteit toe te voegen of bestaande functionaliteit te overschrijven. Gebruik dit bestand bijvoorbeeld om te federeren met nieuwe id-providers.
• Een Relying Party (RP)-bestand dat specifiek is voor één taak en rechtstreeks wordt aangeroepen door de relying party-toepassing, zoals uw web-, mobiele of desktopapplicaties. Voor elke unieke taak, zoals registratie, aanmelding of profielbewerking, is een eigen relying party-beleidsbestand vereist. Dit beleidsbestand is afgeleid van het extensiebestand.

Het overnamemodel is als volgt:

• Het subbeleid op elk niveau kan erven van het hoofbeleid en het uitbreiden door nieuwe elementen toe te voegen.
• Voor complexere scenario's kunt u meer overnameniveaus toevoegen (maximaal 10 in totaal).
• U kunt meer beleid voor vertrouwde partijen toevoegen. Verwijder bijvoorbeeld mijn account, wijzig een telefoonnummer, SAML Relying Party-beleid en meer.

In het volgende diagram ziet u de relatie tussen de beleidsbestanden en de relying party-toepassingen.

Richtlijnen en aanbevolen procedures

Beste praktijken

Binnen een aangepast Azure AD B2C-beleid kunt u uw eigen bedrijfslogica integreren om de gebruikerservaringen te bouwen die u nodig hebt en functionaliteit van de service uit te breiden. We hebben een set aanbevolen procedures en aanbevelingen om aan de slag te gaan.

• Maak uw logica binnen het extensiebeleid of beleid van de relying party. U kunt nieuwe elementen toevoegen, waardoor het basisbeleid wordt overschreven door te verwijzen naar dezelfde id. Met deze aanpak kunt u uw project uitschalen, terwijl u het eenvoudiger maakt om het basisbeleid later te upgraden als Microsoft nieuwe starterspakketten uitbrengt.
• Binnen het basisbeleid raden we u ten zeerste aan te voorkomen dat u wijzigingen aanbrengt. Breng indien nodig opmerkingen aan waar de wijzigingen worden aangebracht.
• Wanneer u een element overschrijft, zoals metagegevens van technische profielen, vermijdt u het kopiëren van het hele technische profiel uit het basisbeleid. Kopieer in plaats daarvan alleen de vereiste sectie van het element. Zie E-mailverificatie uitschakelen voor een voorbeeld van hoe u de wijziging kunt aanbrengen.
• Gebruik het opnemen van technische profielen om duplicatie van technische profielen te verminderen, waarbij de kernfunctionaliteit wordt gedeeld.
• Schrijf niet naar de Microsoft Entra-directory bij het aanmelden, wat kan leiden tot limiteringsproblemen.
• Als uw beleid externe afhankelijkheden heeft, zoals REST API's, zorgt u ervoor dat deze maximaal beschikbaar zijn.
• Voor een betere gebruikerservaring moet u ervoor zorgen dat uw aangepaste HTML-sjablonen wereldwijd worden geïmplementeerd met behulp van online contentlevering. Met Azure Content Delivery Network (CDN) kunt u laadtijden verminderen, bandbreedte besparen en de reactiesnelheid verbeteren.
• Als u een wijziging wilt aanbrengen in het gebruikerstraject, kopieert u het hele gebruikerstraject van het basisbeleid naar het extensiebeleid. Geef een unieke gebruikersbelevings-id op voor het gebruikerstraject dat u hebt gekopieerd. Wijzig vervolgens in het relying party-beleid het standaardelement voor gebruikersbeleving zodat deze verwijst naar het nieuwe gebruikerstraject.

Probleemoplossingsproces

Bij het ontwikkelen met Azure AD B2C-beleid kunt u fouten of uitzonderingen tegenkomen tijdens het uitvoeren van uw gebruikerstraject. Dit kan worden onderzocht met behulp van Application Insights.

• Integreer Application Insights met Azure AD B2C om uitzonderingen te diagnosticeren.
• Met de Azure AD B2C-extensie voor Visual Studio Code kunt u de logboeken openen en visualiseren op basis van een beleidsnaam en -tijd.
• De meest voorkomende fout bij het instellen van aangepast beleid is onjuist opgemaakte XML. Gebruik XML-schemavalidatie om fouten te identificeren voordat u uw XML-bestand uploadt.

Continue integratie

Met behulp van een CI/CD-pijplijn (continue integratie en levering) die u hebt ingesteld in Azure Pipelines, kunt u uw aangepaste Azure AD B2C-beleid opnemen in de automatisering van softwarelevering en codebeheer. Wanneer u implementeert in verschillende Azure AD B2C-omgevingen, bijvoorbeeld dev, test en productie, raden we u aan handmatige processen te verwijderen en geautomatiseerde tests uit te voeren met behulp van Azure Pipelines.

Uw omgeving voorbereiden

U gaat aan de slag met aangepast Azure AD B2C-beleid:

1. Een Azure AD B2C-tenant maken
2. Registreer een webtoepassing met behulp van Azure Portal, zodat u uw beleid kunt testen.
3. Voeg de benodigde beleidssleutels toe en registreer de Identity Experience Framework-toepassingen.
4. Haal het starterspakket voor het Azure AD B2C-beleid op en upload deze naar uw tenant.
5. Nadat u het starterspakket hebt geüpload, test u uw registratie- of aanmeldingsbeleid.
6. U wordt aangeraden Visual Studio Code (VS Code) te downloaden en te installeren. Visual Studio Code is een lichtgewicht maar krachtige broncode-editor, die op uw bureaublad wordt uitgevoerd en beschikbaar is voor Windows, macOS en Linux. Met VS Code kunt u snel navigeren door en uw aangepaste XML-bestanden van Azure AD B2C bewerken door de Azure AD B2C-extensie voor VS Code te installeren.

Verwante inhoud

Nadat u uw Azure AD B2C-beleid hebt ingesteld en getest, kunt u beginnen met het aanpassen van uw beleid. Doorloop de volgende artikelen voor meer informatie over het volgende:

• Voeg claims toe en pas gebruikersinvoer aan met behulp van aangepast beleid. Meer informatie over het definiëren van een claim en het toevoegen van een claim aan de gebruikersinterface door enkele technische profielen voor starterspakketten aan te passen.
• Pas de gebruikersinterface van uw toepassing aan met behulp van een aangepast beleid. Meer informatie over het maken van uw eigen HTML-inhoud en het aanpassen van de inhoudsdefinitie.
• Lokaliseer de gebruikersinterface van uw toepassing met behulp van een aangepast beleid. Meer informatie over het instellen van de lijst met ondersteunde talen en het opgeven van taalspecifieke labels door het element gelokaliseerde resources toe te voegen.
• Tijdens het ontwikkelen en testen van uw beleid kunt u e-mailverificatie uitschakelen. Meer informatie over het overschrijven van metagegevens van een technisch profiel.
• Stel het aanmelden met een Google-account in met aangepaste beleidsregels. Meer informatie over het maken van een nieuwe claimprovider met een technisch OAuth2-profiel. Pas vervolgens het gebruikerstraject aan om de aanmeldingsoptie van Google op te nemen.
• Als u problemen met uw aangepaste beleid wilt vaststellen, kunt u Azure Active Directory B2C-logboeken verzamelen met Application Insights. Meer informatie over het toevoegen van nieuwe technische profielen en het configureren van uw relying party-beleid.
• Als u wilt weten hoe aangepast beleid helemaal zelf wordt gebouwd, leert u hoe u uw eigen aangepaste beleidsregels maakt en uitvoert in azure Active Directory B2C-handleidingreeks.