Azure AD B2C översikt över anpassad princip

Anpassade principer är konfigurationsfiler som definierar beteendet för din Azure Active Directory B2C-klientorganisation (Azure AD B2C). Användarflöden är fördefinierade i Azure AD B2C portalen för de vanligaste identitetsuppgifterna, men anpassade principer kan redigeras fullständigt av en identitetsutvecklare för att slutföra många olika uppgifter.

En anpassad princip är helt konfigurerbar och principdriven. En anpassad princip orkestrerar förtroende mellan entiteter i standardprotokoll. Till exempel, OpenID Anslut, OAuth, SAML och några icke-standard sådana, till exempel REST API-baserade system-till-system-anspråk utbyten. Ramverket skapar användarvänliga, vitmärkta upplevelser.

En anpassad princip representeras som en eller flera XML-formaterade filer som refererar till varandra i en hierarkisk kedja. XML-elementen definierar byggstenarna, interaktionen med användaren och andra parter samt affärslogiken.

Anpassat principstartpaket

Azure AD B2C anpassade principstartpaketet levereras med flera förbyggda principer för att du ska kunna komma igång snabbt. Vart och ett av dessa startpaket innehåller det minsta antalet tekniska profiler och användarresor som krävs för att uppnå de scenarier som beskrivs:

• LocalAccounts – Tillåter endast användning av lokala konton.
• SocialAccounts – Tillåter endast användning av sociala (eller federerade) konton.
• SocialAndLocalAccounts – Gör det möjligt att använda både lokala och sociala konton. De flesta av våra exempel refererar till den här principen.
• SocialAndLocalAccountsWithMFA – Aktiverar alternativ för social, lokal och multifaktorautentisering.

I Azure AD B2C exempel GitHub lagringsplatsenhittar du exempel för flera förbättrade Azure AD B2C anpassade CIAM-användarresor. Till exempel förbättringar av principer för lokala konton, förbättringar av principer för sociala konton, MFA-förbättringar, förbättringar av användargränssnittet, allmänna förbättringar, appmigrering, användarmigrering, villkorlig åtkomst, webbtest och CI/CD.

Förstå grunderna

Anspråk

Ett anspråk ger tillfällig lagring av data under en Azure AD B2C principkörning. Den kan lagra information om användaren, till exempel förnamn, efternamn eller andra anspråk som hämtas från användaren eller andra system (anspråksutbyten). Anspråksschemat är den plats där du deklarerar dina anspråk.

När principen körs skickar Azure AD B2C och tar emot anspråk till och från interna och externa parter och skickar sedan en delmängd av dessa anspråk till ditt förlitande partsprogram som en del av token. Anspråk används på följande sätt:

• Ett anspråk sparas, läses eller uppdateras mot kataloganvändarobjektet.
• Ett anspråk tas emot från en extern identitetsprovider.
• Anspråk skickas eller tas emot med hjälp av en anpassad REST API tjänst.
• Data samlas in som anspråk från användaren under registrering eller redigering av profilflöden.

Manipulera dina anspråk

Anspråksomvandlarna är fördefinierade funktioner som kan användas för att konvertera ett angivna anspråk till ett annat, utvärdera ett anspråk eller ange ett anspråksvärde. Du kan till exempel lägga till ett objekt i en strängsamling, ändra skiftfallet för en sträng eller utvärdera ett datum- och tidsanspråk. En anspråksomvandling anger en transformeringsmetod.

Anpassa och lokalisera ditt användargränssnitt

Om du vill samla in information från användarna genom att presentera en sida i webbläsaren använder du den självinfogade tekniska profilen. Du kan redigera din självbetjänade tekniska profil för att lägga till anspråk och anpassa användarindata.

Om du vill anpassa användargränssnittet för din självinfogade tekniska profil anger du en URL i innehållsdefinitionselementet med anpassat HTML-innehåll. I den självinfogade tekniska profilen pekar du på det här innehållsdefinitions-ID:t.

Om du vill anpassa språkspecifika strängar använder du lokaliseringselementet. En innehållsdefinition kan innehålla en lokaliseringsreferens som anger en lista över lokaliserade resurser som ska läsas in. Azure AD B2C sammanfogar användargränssnittets element med HTML-innehåll som läses in från din URL och visar sedan sidan för användaren.

Översikt över princip för förlitande part

Ett förlitande partsprogram, som i SAML-protokollet kallas för en tjänstleverantör, anropar den förlitande partsprincipen för att köra en specifik användarresa. Principen för förlitande part anger vilken användarresa som ska köras och en lista över anspråk som token innehåller.

Alla förlitande partsprogram som använder samma princip får samma tokenanspråk och användaren går igenom samma användarresa.

Användarresor

Med användarresor kan du definiera affärslogiken med den sökväg som användaren följer för att få åtkomst till ditt program. Användaren tas genom användarresan för att hämta de anspråk som ska presenteras för ditt program. En användarresa bygger på en sekvens med orkestreringssteg. En användare måste nå det sista steget för att hämta en token.

Följande anvisningar beskriver hur du kan lägga till orkestreringssteg i principen för startpaketet för sociala och lokala konton. Här är ett exempel på ett REST API som har lagts till.

Orkestreringssteg

Orkestreringssteget refererar till en metod som implementerar dess avsedda syfte eller funktioner. Den här metoden kallas för en teknisk profil. När din användarresa behöver förgrening för att bättre representera affärslogiken refererar orkestreringssteget till underresan. En underresa innehåller en egen uppsättning orkestreringssteg.

En användare måste nå det sista orkestreringssteget i användarresan för att hämta en token. Men användarna kanske inte behöver färdas genom alla orkestreringssteg. Orkestreringssteg kan köras villkorligt baserat på förhandsvillkor som definierats i orkestreringssteget.

När ett orkestreringssteg har slutförts Azure AD B2C de utgående anspråken i anspråksdepån. Anspråken i anspråkspåsen kan användas av eventuella ytterligare orkestreringssteg under användarresan.

Följande diagram visar hur användarresans orkestreringssteg kan komma åt anspråksdepån.

Teknisk profil

En teknisk profil tillhandahåller ett gränssnitt för att kommunicera med olika typer av parter. En användarresa kombinerar anropande tekniska profiler via orkestreringssteg för att definiera affärslogiken.

Alla typer av tekniska profiler delar samma koncept. Du skickar inkommande anspråk, kör anspråksomvandling och kommunicerar med den konfigurerade parten. När processen har slutförts returnerar den tekniska profilen utgående anspråk till anspråksdepån. Mer information finns i översikten över tekniska profiler.

Teknisk profil för validering

När en användare interagerar med användargränssnittet kanske du vill verifiera de data som samlas in. Om du vill interagera med användaren måste du använda en självbestämd teknisk profil.

För att verifiera användarindata anropas en teknisk profil för validering från den självinfogade tekniska profilen. En teknisk profil för validering är en metod för att anropa alla icke-interaktiva tekniska profiler. I det här fallet kan den tekniska profilen returnera utgående anspråk eller ett felmeddelande. Felmeddelandet återges för användaren på skärmen så att användaren kan försöka igen.

Följande diagram illustrerar hur Azure AD B2C använder en teknisk valideringsprofil för att verifiera autentiseringsuppgifterna för användaren.

Arvsmodell

Varje startpaket innehåller följande filer:

• En basfil som innehåller de flesta av definitionerna. För att hjälpa till med felsökning och långsiktigt underhåll av dina principer kan du försöka minimera antalet ändringar som du gör i den här filen.
• En lokaliseringsfil som innehåller lokaliseringssträngarna. Den här principfilen härleds från basfilen. Använd den här filen för att hantera olika språk som passar dina kunders behov.
• En fil för tillägg som innehåller de unika konfigurationsändringarna för din klientorganisation. Den här principfilen härleds från lokaliseringsfilen. Använd den här filen för att lägga till nya funktioner eller åsidosätta befintliga funktioner. Använd till exempel den här filen för att federera med nya identitetsproviders.
• En RP-fil (Relying Party) som är den enda uppgiftsfokuserade filen som anropas direkt av det förlitande partsprogrammet, till exempel dina webb-, mobil- eller skrivbordsprogram. Varje unik uppgift, till exempel registrering, inloggning eller profilredigering, kräver en egen principfil för förlitande part. Den här principfilen härleds från filtillägget.

Arvsmodellen ser ut så här:

• Den underordnade principen på valfri nivå kan ärva från den överordnade principen och utöka den genom att lägga till nya element.
• För mer komplexa scenarier kan du lägga till fler arvsnivåer (upp till 10 totalt).
• Du kan lägga till fler principer för förlitande part. Ta till exempel bort mitt konto, ändra ett telefonnummer, en SAML-princip för förlitande part med mera.

Följande diagram visar relationen mellan principfilerna och de förlitande partprogrammen.

Vägledning och metodtips

Bästa praxis

I en Azure AD B2C anpassad princip kan du integrera din egen affärslogik för att skapa de användarupplevelser som du behöver och utöka tjänstens funktioner. Vi har en uppsättning metodtips och rekommendationer för att komma igång.

• Skapa din logik i tilläggsprincipen, eller principen för förlitande part. Du kan lägga till nya element som åsidosätter basprincipen genom att referera till samma ID. Med den här metoden kan du skala ut projektet samtidigt som det blir enklare att uppgradera basprincipen senare om Microsoft släpper nya startpaket.
• I basprincipen rekommenderar vi starkt att du inte gör några ändringar. Vid behov kan du lämna kommentarer där ändringarna görs.
• Undvik att kopiera hela den tekniska profilen från basprincipen när du åsidosätter ett element, till exempel tekniska profilmetadata. Kopiera i stället endast det avsnitt som krävs för elementet . Ett exempel på hur du gör ändringen finns i Inaktivera e-postverifiering.
• Om du vill minska dupliceringen av tekniska profiler, där kärnfunktionerna delas, använder du inkludering av teknisk profil.
• Undvik att skriva till Azure AD-katalogen under inloggningen, vilket kan leda till begränsningsproblem.
• Om principen har externa beroenden, till exempel REST-API:er, ser du till att de har hög tillgängliga.
• För en bättre användarupplevelse bör du se till att dina anpassade HTML-mallar distribueras globalt med onlineinnehållsleverans. Med Azure Content Delivery Network (CDN) kan du minska inläsningstiderna, spara bandbredd och förbättra svarstiden.
• Om du vill göra en ändring i användarresan kopierar du hela användarresan från basprincipen till tilläggspolicyn. Ange ett unikt användarresa-ID för den användarresa som du har kopierat. I den förlitande partsprincipen ändrardu sedan standardelementet för användarresa så att det pekar på den nya användarresan.

Felsökning

När du utvecklar Azure AD B2C principer kan du få fel eller undantag när du kör användarresan. kan undersökas med application Insights.

• Integrera Application Insights med Azure AD B2C för att diagnostisera undantag.
• Tillägget Azure AD B2C för Visual Studio Code kan hjälpa dig att komma åt och visualisera loggarna baserat på ett principnamn och en tid.
• Det vanligaste felet vid inställning av anpassade principer är felaktigt formaterad XML. Använd XML-schemavalidering för att identifiera fel innan du laddar upp XML-filen.

Kontinuerlig integrering

Genom att använda en pipeline för kontinuerlig integrering och leverans (CI/CD) som du ställer in i Azure Pipelines kan du inkludera dina anpassade Azure AD B2C-principer i automatiseringen av programvaruleverans och kodkontroll. När du distribuerar till Azure AD B2C miljöer, till exempel dev, test och produktion, rekommenderar vi att du tar bort manuella processer och utför automatiserad testning med hjälp av Azure Pipelines.

Förbered din miljö

Du kommer igång med Azure AD B2C anpassad princip:

1. Skapa en Azure AD B2C-klient
2. Registrera ett webbprogram med Azure Portal så att du kan testa principen.
3. Lägg till nödvändiga principnycklar och registrera Identity Experience Framework program.
4. Hämta startpaketet Azure AD B2C princip och ladda upp till din klientorganisation.
5. När du har överfört startpaketet kan du testa din registrering eller inloggningsprincip.
6. Vi rekommenderar att du laddar ned och installerar Visual Studio Code (VS Code). Visual Studio Kod är en enkel men kraftfull källkodsredigerare som körs på skrivbordet och är tillgänglig för Windows, macOS och Linux. Med VS Code kan du snabbt navigera och redigera XML Azure AD B2C för anpassade principfiler genom att installera Azure AD B2C för VS Code

Nästa steg

När du har ställt in och Azure AD B2C din princip kan du börja anpassa principen. Gå igenom följande artiklar för att lära dig hur du:

• Lägg till anspråk och anpassa användarindata med anpassade principer. Lär dig hur du definierar ett anspråk och lägger till ett anspråk i användargränssnittet genom att anpassa några av de tekniska profilerna för startpaketet.
• Anpassa användargränssnittet för ditt program med hjälp av en anpassad princip. Lär dig hur du skapar ditt eget HTML-innehåll och anpassar innehållsdefinitionen.
• Lokalisera användargränssnittet för ditt program med hjälp av en anpassad princip. Lär dig hur du ställer in listan över språk som stöds och anger språkspecifika etiketter genom att lägga till elementet för lokaliserade resurser.
• Under principutvecklingen och testningen kan du inaktivera e-postverifiering. Lär dig hur du skriver över metadata för en teknisk profil.
• Konfigurera inloggning med ett Google-konto med anpassade principer. Lär dig hur du skapar en ny anspråksprovider med en teknisk OAuth2-profil. Anpassa sedan användarresan för att inkludera alternativet för Google-inloggning.
• Om du vill diagnostisera problem med dina anpassade principer kan du samla Azure Active Directory B2C-loggar med Application Insights. Lär dig hur du lägger till nya tekniska profiler och konfigurerar din förlitande partsprincip.