Overzicht van aangepaste Azure AD B2C-beleidsregels

  • Artikel
  • 10 minuten om te lezen

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, kunnen aangepaste beleidsregels volledig worden bewerkt door een identiteitsontwikkelaar om vele verschillende taken uit te voeren.

Een aangepast beleid is volledig configureerbaar en beleidsgestuurd. Een aangepast beleid organiseert vertrouwen tussen entiteiten in standaardprotocollen. Bijvoorbeeld OpenID Connect, OAuth, SAML en enkele niet-standaard protocollen, zoals op REST-API gebaseerde systeem-naar-systeem claimuitwisselingen. Het framework creëert gebruikersvriendelijke white label-ervaringen.

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

Starterspakket voor aangepaste beleidsregels

Het starterspakket voor aangepaste Azure AD B2C-beleidsregels wordt geleverd met een aantal vooraf gebouwde 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: Maakt alleen het gebruik van lokale accounts mogelijk.
  • SocialAccounts: Maakt alleen het gebruik van sociale (of federatieve) accounts mogelijk.
  • SocialAndLocalAccounts: Maakt het gebruik van zowel lokale als sociale accounts mogelijk. De meeste voorbeelden verwijzen naar dit beleid.
  • SocialAndLocalAccountsWithMFA: Maakt opties voor sociale, lokale en meervoudige verificatie mogelijk.

In de GitHub-opslagplaats met Azure AD B2C-voorbeelden vindt u voorbeelden voor een aantal verbeterde aangepaste CIAM-gebruikerstrajecten voor Azure AD B2C. Bijvoorbeeld verbeteringen van het beleid voor lokale accounts, verbeteringen van het beleid voor sociale accounts, MFA-verbeteringen, gebruikersinterfaceverbeteringen, algemene verbeteringen, app-migratie, gebruikersmigratie, voorwaardelijke toegang, webtest en CI/CD.

De basisbeginselen begrijpen

Claims

Een claim maakt tijdelijke opslag van gegevens mogelijk tijdens de uitvoering van een Azure AD B2C-beleid. Het kan informatie over de gebruiker opslaan, zoals voornaam, achternaam of een andere claim die is verkregen van de gebruiker of andere systemen (claimuitwisselingen). Het claimsschema is de plek 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 de registratie- of profielbewerkingsstroom.

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.

Uw gebruikersinterface aanpassen en lokaliseren

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

Als u de gebruikersinterface wilt aanpassen voor uw zelf-gecontroleerde technische profiel, geeft u een URL op in het inhoudsdefinitie-element met aangepaste HTML-inhoud. In het zelf-gecontroleerde technische profiel wijst u naar deze inhoudsdefinitie-id.

Gebruik het lokalisatie-element om taalspecifieke tekenreeksen aan te passen. Een inhoudsdefinitie kan een lokalisatie-verwijzing bevatten waarmee een lijst met gelokaliseerde resources wordt opgegeven die moeten worden geladen. Azure AD B2C combineert elementen van de gebruikersinterface met de HTML-inhoud die vanaf de URL wordt geladen en presenteert vervolgens de pagina aan de gebruiker.

Overzicht van Relying Party-beleid

Een Relying Party-toepassing, die in het SAML-protocol een serviceprovider wordt genoemd, roept het Relying Party-beleid aan om een specifiek gebruikerstraject uit te voeren. Het Relying Party-beleid geeft het gebruikerstraject op dat moet worden uitgevoerd, en een lijst met claims die het token bevat.

Diagram dat de stroom voor beleidsuitvoering weergeeft

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

Gebruikersbelevingen

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 geleid om de claims op te halen die aan uw toepassing moeten worden gepresenteerd. Een gebruikerstraject bestaat uit een reeks indelingsstappen. Een gebruiker moet de laatste stap bereiken om een token te verkrijgen.

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

aangepast gebruikerstraject

Indelingsstappen

De indelingsstap verwijst naar een methode die de beoogde doelstelling of functionaliteit implementeert. Deze methode wordt een technisch profiel genoemd. Wanneer uw gebruikerstraject vertakking nodig heeft om de bedrijfslogica beter weer te geven, verwijst de indelingsstap naar een subtraject. Een subtraject bevat zijn eigen set indelingsstappen.

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

Nadat een indelingsstap is voltooid, slaat Azure AD B2C de uitgevoerde claims op in de claimverzameling. De claims in de claimverzameling kunnen worden gebruikt door verdere indelingsstappen in het gebruikerstraject.

In het volgende diagram ziet u hoe de indelingsstappen van het gebruikerstraject toegang kunnen krijgen tot de claimverzameling.

Azure AD B2C-gebruikerstraject

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 de claimverzameling. Zie Overzicht van technische profielen voor meer informatie.

Technisch validatieprofiel

Wanneer een gebruiker communiceert met de gebruikersinterface, kunt u de verzamelde gegevens valideren. Om met de gebruiker te communiceren, moet er een zelf-gecontroleerd technisch profiel worden gebruikt.

Om de gebruikersinvoer te valideren, wordt een technisch validatieprofiel aangeroepen vanuit het zelf-gecontroleerde technische profiel. Een technisch validatieprofiel 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 op het scherm weergegeven aan de gebruiker, zodat de gebruiker het opnieuw kan proberen.

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

Diagram van technisch validatieprofiel

Overnamemodel

Elk starterspakket bevat de volgende bestanden:

  • Een basisbestand dat de meeste definities bevat. Probeer het aantal wijzigingen dat u aanbrengt in dit bestand te minimaliseren om te helpen met probleemoplossing en langetermijnonderhoud van uw beleidsregels.
  • Een lokalisatiebestand dat de lokalisatietekenreeksen bevat. Dit beleidsbestand is afgeleid van het basisbestand. Gebruik dit bestand om verschillende talen op te nemen om aan de behoeften van uw klant te voldoen.
  • Een extensiebestand dat de unieke configuratiewijzigingen voor uw tenant bevat. 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-bestand (RP) dat het op één taak gerichte bestand is dat rechtstreeks wordt aangeroepen door de Relying Party-toepassing, zoals uw web-, mobiele of desktoptoepassingen. 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 onderliggende beleid op een bepaald niveau kan overnemen van het bovenliggende beleid 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 Relying Party-beleidsregels toevoegen. Bijvoorbeeld mijn account verwijderen, een telefoonnummer wijzigen, SAML Relying Party-beleid en meer.

In het volgende diagram ziet u de relatie tussen de beleidsbestanden en de Relying Party-toepassingen.

Diagram dat het overnamemodel voor vertrouwensframeworkbeleid weergeeft

Richtlijnen en aanbevolen procedures

Aanbevolen procedures

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

  • Maak uw logica binnen het extensiebeleid of Relying Party-beleid. U kunt nieuwe elementen toevoegen, waardoor het basisbeleid wordt overschreven door te verwijzen naar dezelfde id. Met deze aanpak kunt u uw project uitschalen en is het eenvoudiger om het basisbeleid later te upgraden als Microsoft nieuwe starterspakketten uitbrengt.
  • Binnen het basisbeleid raden we u ten zeerste aan geen wijzigingen aan te brengen. Wanneer u toch wijzigingen moet aanbrengen, voorzie deze dan van opmerkingen.
  • Wanneer u een element overschrijft, zoals metagegevens van een technisch profiel, kopieer dan niet 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 aanbrengt.
  • Om duplicatie van technische profielen te verminderen, gebruikt u opname van technische profielen waar kernfunctionaliteit wordt gedeeld.
  • Schrijf niet naar de Azure AD Directory tijdens het aanmelden, want dit kan leiden tot beperkingsproblemen.
  • Als uw beleid externe afhankelijkheden heeft, zoals REST-API's, zorgt u ervoor dat deze maximaal beschikbaar zijn.
  • Voor een betere gebruikerservaring zorgt u ervoor dat uw aangepaste HTML-sjablonen globaal worden geïmplementeerd met behulp van online inhoudslevering. Met het Azure Content Delivery Network (CDN) kunt u laadtijden verkorten, bandbreedte besparen en de reactiesnelheid verbeteren.
  • Als u een wijziging wilt aanbrengen in het gebruikerstraject, kopieert u het hele gebruikerstraject uit het basisbeleid naar het extensiebeleid. Geef een unieke gebruikerstraject-id op voor het gebruikerstraject dat u hebt gekopieerd. Wijzig vervolgens in het Relying Party-beleid het standaardgebruikerstraject-element zodat dit naar het nieuwe gebruikerstraject verwijst.

Problemen oplossen

Bij het ontwikkelen met Azure AD B2C-beleidsregels kunt u fouten of uitzonderingen tegenkomen terwijl u uw gebruikerstraject uitvoert. Deze kunnen worden onderzocht met behulp van Application Insights.

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-beleidsregels opnemen in uw automatisering van softwarelevering en codebeheer. Wanneer u implementeert in verschillende Azure AD B2C-omgevingen, zoals ontwikkelen, testen en productie, raden we u aan handmatige processen te verwijderen en geautomatiseerde tests uit te voeren met behulp van Azure Pipelines.

Uw omgeving voorbereiden

Ga als volgt aan de slag met aangepaste Azure AD B2C-beleidsregels:

  1. Een Azure AD B2C-tenant maken
  2. Registreer een webtoepassing met behulp van de Azure-portal zodat u uw beleid kunt testen.
  3. Voeg de benodigde beleidssleutels toe en registreer de Identity Experience Framework-toepassingen.
  4. Download het starterspakket voor Azure AD B2C-beleidsregels en upload het 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 voor Windows, macOS en Linux die u kunt uitvoeren op uw computer. Met VS Code kunt u snel door uw XML-bestanden voor aangepaste Azure AD B2C-beleidsregels navigeren en deze bewerken door de Azure AD B2C-extensie voor VS Code te installeren.

Volgende stappen

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