Översikt över anpassad princip för Azure AD B2C

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 helt av en identitetsutvecklare för att utföra många olika uppgifter.

En anpassad princip är helt konfigurerbar och principdriven. En anpassad princip samordnar förtroendet mellan entiteter i standardprotokoll. Till exempel OpenID-Anslut, OAuth, SAML och några icke-standardbaserade, till exempel REST API-baserade system-till-system-anspråksutbyten. 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ärslogik.

Startpaket för anpassad princip

Azure AD B2C-startpaketet för anpassad princip levereras med flera fördefinierade principer för att snabbt komma igång. Var och en av dessa startpaket innehåller det minsta antalet tekniska profiler och användarresor som behövs för att uppnå de scenarier som beskrivs:

• LocalAccounts – Aktiverar endast användning av lokala konton.
• SocialAccounts – Aktiverar endast användning av sociala (eller federerade) konton.
• SocialAndLocalAccounts – Aktiverar användning av både lokala och sociala konton. De flesta av våra exempel refererar till den här principen.
• SocialAndLocalAccountsWithMFA – Aktiverar sociala, lokala och multifaktorautentiseringsalternativ.

I Azure AD B2C-exemplen GitHub lagringsplats hittar du exempel för flera förbättrade anpassade CIAM-användarresor i Azure AD B2C. Till exempel förbättringar av lokala kontoprinciper, 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 tillhandahåller 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 erhållits 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 och tar Azure AD B2C 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 partprogram som en del av token. Anspråk används på följande sätt:

• Ett anspråk sparas, läss 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 registrerings- eller redigeringsprofilflödena.

Manipulera dina anspråk

Anspråkstransformeringarna är fördefinierade funktioner som kan användas för att konvertera ett visst 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 skiftläget för en sträng eller utvärdera ett datum- och tidsanspråk. En anspråkstransformering 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älvsäkra tekniska profilen. Du kan redigera din egensäkra tekniska profil för att lägga till anspråk och anpassa användarindata.

Om du vill anpassa användargränssnittet för din egensäkrade tekniska profil anger du en URL i innehållsdefinitionselementet med anpassat HTML-innehåll. I den självsäkra 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.

Principöversikt för förlitande part

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

Alla program från förlitande part som använder samma princip får samma tokenanspråk och användaren genomgår samma användarresa.

Användarresor

Med användarresor kan du definiera affärslogik med sökvägen som användaren följer för att få åtkomst till ditt program. Användaren tas genom användarens resa 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 instruktioner beskriver hur du kan lägga till orkestreringssteg i principen för startpaket för sociala och lokala konton . Här är ett exempel på ett REST API-anrop som har lagts till.

Orkestreringssteg

Orkestreringssteget refererar till en metod som implementerar dess avsedda syfte eller funktionalitet. 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ärslogik 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 gå igenom alla orkestreringssteg. Orkestreringssteg kan köras villkorligt baserat på förhandsvillkor som definierats i orkestreringssteget.

När ett orkestreringssteg har slutförts lagrar Azure AD B2C utdataanspråken i anspråkspåsen. Anspråken i anspråkspåsen kan användas av ytterligare orkestreringssteg under användarresan.

Följande diagram visar hur användarens orkestreringssteg kan komma åt anspråkspåsen.

Teknisk profil

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

Alla typer av tekniska profiler delar samma koncept. Du skickar indataanspråk, kör anspråkstransformering och kommunicerar med den konfigurerade parten. När processen är klar returnerar den tekniska profilen utdataanspråken till anspråkspåsen. 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. För att interagera med användaren måste en självsäkrad teknisk profil användas.

För att verifiera användarindata anropas en teknisk valideringsprofil från den självsäkra tekniska profilen. En teknisk valideringsprofil är en metod för att anropa alla icke-interaktiva tekniska profiler. I det här fallet kan den tekniska profilen returnera utdataanspråk eller ett felmeddelande. Felmeddelandet återges till 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 användarautentiseringsuppgifterna.

Arvsmodell

Varje startpaket innehåller följande filer:

• En basfil som innehåller de flesta definitionerna. Om du vill ha hjälp 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 med 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 om du vill lägga till nya funktioner eller åsidosätta befintliga funktioner. Använd till exempel den här filen för att federera med nya identitetsprovidrar.
• En förlitande partsfil (RP) som är den enda uppgiftsfokuserade filen som anropas direkt av det förlitande partprogrammet, 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 filnamnstillägget.

Arvsmodellen är följande:

• Den underordnade principen på vilken nivå som helst 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, 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 anpassad Azure AD B2C-princip kan du integrera din egen affärslogik för att skapa de användarupplevelser som du behöver och utöka funktionerna i tjänsten. Vi har en uppsättning metodtips och rekommendationer för att komma igång.

• Skapa logiken 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 och göra det enklare att uppgradera basprincipen senare om Microsoft släpper nya startpaket.
• I basprincipen rekommenderar vi starkt att du undviker att göra några ändringar. När det behövs kan du kommentera var ändringarna görs.
• När du åsidosättar ett element, till exempel tekniska profilmetadata, bör du undvika att kopiera hela den tekniska profilen från basprincipen. Kopiera i stället endast det obligatoriska avsnittet i -elementet. Se Inaktivera e-postverifiering för ett exempel på hur du gör ändringen.
• Om du vill minska dupliceringen av tekniska profiler, där kärnfunktioner delas, använder du inkludering av tekniska profiler.
• 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änglighet.
• För en bättre användarupplevelse kontrollerar du att dina anpassade HTML-mallar distribueras globalt med hjälp av onlineinnehållsleverans. Med Azure Content Delivery Network (CDN) kan du minska belastningstiderna, spara bandbredd och förbättra svarshastigheten.
• Om du vill göra en ändring i användarresan kopierar du hela användarresan från basprincipen till tilläggsprincipen. Ange ett unikt användarresa-ID för den användarresa som du har kopierat. I principen för förlitande part ändrar du sedan standardelementet för användarresan så att det pekar på den nya användarresan.

Felsökning

När du utvecklar med Azure AD B2C-principer kan du stöta på fel eller undantag när du kör din användarresa. kan undersökas med application Insights.

• Integrera Program Insights med Azure AD B2C för att diagnostisera undantag.
• Azure AD B2C-tillägget 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 konfiguration 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 har konfigurerat i Azure Pipelines kan du inkludera dina anpassade Principer för Azure AD B2C i automatiseringen av programvaruleverans och kodkontroll. När du distribuerar till olika 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 anpassad princip för Azure AD B2C:

1. Skapa en Azure AD B2C-klient
2. Registrera ett webbprogram med hjälp av Azure Portal så att du kan testa principen.
3. Lägg till nödvändiga principnycklar och registrera Identity Experience Framework-programmen.
4. Hämta startpaketet för Azure AD B2C-principen och ladda upp det till din klientorganisation.
5. När du har laddat upp startpaketet testar du din registrerings- eller inloggningsprincip.
6. Vi rekommenderar att du laddar ned och installerar Visual Studio Code (VS Code). Visual Studio Code ä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 igenom och redigera dina ANPASSADE XML-filer för Azure AD B2C-principer genom att installera Azure AD B2C-tillägget för VS Code

Nästa steg

När du har konfigurerat och testat din Azure AD B2C-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 konfigurerar listan över språk som stöds och tillhandahåller språkspecifika etiketter genom att lägga till elementet lokaliserade resurser.
• Under din principutveckling och testning kan du inaktivera e-postverifiering. Lär dig hur du skriver över en teknisk profilmetadata.
• 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 så att den inkluderar inloggningsalternativet för Google.
• Om du vill diagnostisera problem med dina anpassade principer kan du samla in Azure Active Directory B2C-loggar med Application Insights. Lär dig hur du lägger till nya tekniska profiler och konfigurerar din princip för förlitande part.