Felsöka anpassade azure AD B2C-principer och användarflöden

Fel vid lösenordsåterställning

Det här felet uppstår när självbetjäningsfunktionen för lösenordsåterställning inte är aktiverad i ett användarflöde. Om du väljer länken Har du glömt lösenordet? utlöser inte användarflödet för lösenordsåterställning. I stället returneras felkoden AADB2C90118 till ditt program.

Det finns två lösningar på det här problemet:

• Svara med en ny autentiseringsbegäran med hjälp av användarflödet för lösenordsåterställning i Azure AD B2C.
  • Använd rekommenderad SSPR-upplevelse (självbetjäning av lösenordsåterställning).

Användaren avbröt åtgärden

Azure AD B2C-tjänsten kan också returnera ett fel till ditt program när en användare avbryter en åtgärd. Följande är exempel på scenarier där en användare utför en avbrytande åtgärd.

• En användarpolicy använder den rekommenderade upplevelsen för självbetjäning vid lösenordsåterställning (SSPR) med ett lokalt konsumentkonto. Användaren väljer länken Har du glömt lösenordet? och väljer sedan knappen Avbryt innan användarflödesupplevelsen är klar. I det här fallet returnerar Azure AD B2C-tjänsten felkod AADB2C90091 till ditt program.
• En användare väljer att autentisera med en extern identitetsprovider, till exempel LinkedIn. Användaren väljer knappen Avbryt innan den autentiserar till själva identitetsprovidern. I det här fallet returnerar Azure AD B2C-tjänsten felkod AADB2C90273 till ditt program. Läs mer om felkoder för Azure Active Directory B2C-tjänstretur.

Om du vill hantera det här felet hämtar du felbeskrivningen för användaren och svarar med en ny autentiseringsbegäran med samma användarflöde.

Om du använder anpassade principer för Azure Active Directory B2C (Azure AD B2C) kan det uppstå problem med XML-format för principspråk eller körningsproblem. Den här artikeln beskriver några verktyg och tips som kan hjälpa dig att identifiera och lösa problem.

Den här artikeln fokuserar på att felsöka konfigurationen av din anpassade Azure AD B2C-policy. Den behandlar inte den förlitande partens applikation eller dess identitetsbibliotek.

Översikt över Korrelations-ID för Azure AD B2C

Korrelations-ID för Azure AD B2C är ett unikt identifierarvärde som är kopplat till auktoriseringsbegäranden. Den går igenom alla orkestreringssteg som en användare går igenom. Med korrelations-ID:t kan du:

• Identifiera inloggningsaktiviteten i din applikation och spåra policyns prestanda.
• Leta upp inloggningsbegärans Azure Application Insights-loggar.
• Skicka korrelations-ID:t till rest-API:et och använd det för att identifiera inloggningsflödet.

Korrelations-ID ändras varje gång en ny session upprättas. När du felsöker dina principer kontrollerar du att du stänger befintliga webbläsarflikar eller öppnar en ny webbläsare i privat läge.

Förutsättningar

• Slutför stegen i Kom igång med anpassade principer i Active Directory B2C.

Hämta korrelations-ID:t för Azure AD B2C

Du hittar korrelations-ID:t på registrerings- eller inloggningssidan för Azure AD B2C. I webbläsaren väljer du Visa källa. Korrelationen visas som en kommentar överst på sidan.

Kopiera korrelations-ID:t och fortsätt sedan inloggningsflödet. Använd korrelations-ID:t för att observera inloggningsbeteendet. Mer information finns i Felsökning med Application Insights.

Upprepa korrelations-ID:t för Azure AD B2C

Du kan inkludera korrelations-ID:t i dina Azure AD B2C-token. Så här inkluderar du korrelations-ID:t:

1. Öppna tilläggsfilen för policyn. Till exempel SocialAndLocalAccounts/TrustFrameworkExtensions.xml.

2. Sök efter elementet BuildingBlocks . Om elementet inte finns lägger du till det.

3. Leta upp elementet ClaimsSchema . Om elementet inte finns lägger du till det.

4. Lägg till korrelations-ID-anspråket i elementet ClaimsSchema .

   <!-- 
   <BuildingBlocks>
     <ClaimsSchema> -->
       <ClaimType Id="correlationId">
         <DisplayName>correlation ID</DisplayName>
         <DataType>string</DataType>
       </ClaimType>
     <!-- 
     </ClaimsSchema>
   </BuildingBlocks>-->
   

5. Öppna den förlitande partsfilen för din princip. Till exempel SocialAndLocalAccounts/SignUpOrSignIn.xml fil. Utdatafältet läggs till i token efter en lyckad användarupplevelse och skickas till applikationen. Ändra det tekniska profilelementet i avsnittet förlitande part för att lägga correlationId till som ett utdataanspråk.

   <RelyingParty>
     <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
     <TechnicalProfile Id="PolicyProfile">
       <DisplayName>PolicyProfile</DisplayName>
       <Protocol Name="OpenIdConnect" />
       <OutputClaims>
         ...
         <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
       </OutputClaims>
       <SubjectNamingInfo ClaimType="sub" />
     </TechnicalProfile>
   </RelyingParty>
   

Felsökning med Application Insights

Om du vill diagnostisera problem med dina anpassade principer använder du Application Insights. Application Insights spårar aktiviteten i din anpassade användarpolicyresa. Det är ett sätt att diagnostisera undantag och observera utbytet av anspråk mellan Azure AD B2C och de olika anspråksprovidrar. Anspråksprovidrar definieras av tekniska profiler, till exempel identitetsprovidrar, API-baserade tjänster, Azure AD B2C-användarkatalogen och andra tjänster.

Vi rekommenderar att du installerar Azure AD B2C-tillägget för VS Code. Med Azure AD B2C-tillägget ordnas loggarna efter principnamn, korrelations-ID (Application Insights visar den första siffran i korrelations-ID:t) och loggtidsstämpeln. Den här funktionen hjälper dig att hitta relevant logg baserat på den lokala tidsstämpeln och se användarresan som körs av Azure AD B2C.

Ett flöde för enkel inloggning kan utfärda mer än en Azure Application Insights-spårning. I följande skärmdump har policyn B2C_1A_signup_signin tre loggar. Varje logg representerar en del av inloggningsflödet.

Följande skärmbild visar Azure AD B2C-tillägget för VS Code med Azure Application Insights-spårningsutforskaren.

Filtrera spårningsloggen

Med fokus på Azure AD B2C-spårningsutforskaren börjar du skriva den första siffran i korrelations-ID:t eller en tid som du vill hitta. Du ser en filterruta längst upp till höger i Azure AD B2C-spårningsutforskaren som visar vad du har skrivit hittills och matchande spårningsloggar är markerade.

Om du hovrar över filterrutan och väljer Aktivera filter på typ visas endast matchande spårningsloggar. Använd knappen "X" Rensa för att rensa filtret.

Application Insights-spårningslogginformation

När du väljer en Azure Application Insights-spårning öppnar tillägget informationsfönstret Application Insights med följande information:

• Application Insights – Allmän information om spårningsloggen, inklusive principnamn, korrelations-ID, Azure Application Insights-spårnings-ID och spårningstidsstämpel.
• Tekniska profiler – Lista över tekniska profiler som visas i spårningsloggen.
• Anspråk – alfabetisk lista över anspråk som visas i spårningsloggen och deras värden. Om ett anspråk visas i spårningsloggen flera gånger med olika värden, anger ett => tecken det senaste värdet. Du kan granska dessa anspråk för att avgöra om förväntade anspråksvärden har angetts korrekt. Om du till exempel har en förutsättning som kontrollerar ett anspråksvärde kan anspråksavsnittet hjälpa dig att avgöra varför ett förväntat flöde beter sig annorlunda.
• Anspråkstransformering – Lista över anspråkstransformeringar som visas i spårningsloggen. Varje transformation av påståenden innehåller indatapåståenden, indataparametrar och utgångspåståenden. Avsnittet om anspråkstransformering ger insikter om de data som skickas in och resultatet av anspråkstransformeringen.
• Tokens – lista över token som visas i spårningsloggen. Tokenen inkluderar token från den underliggande federerade OAuth och OpenId Connect-identitetsprovidern. Den federerade identitetsproviderns token ger information om hur identitetsprovidern returnerar anspråken till Azure AD B2C så att du kan mappa utdataanspråk för identitetsproviderns tekniska profil.
• Undantag – Lista över undantag eller allvarliga fel som visas i spårningsloggen.
• Application Insights JSON – Rådata som returneras från Application Insights.

Följande skärmbild visar ett exempel på application insights-spårningsloggens informationsfönster.

Felsöka JWTs

För JWT-validering och felsökning kan du avkoda JWT:er med hjälp av en webbplats som https://jwt.ms. Skapa ett testprogram som kan omdirigeras till https://jwt.ms för tokenkontroll. Om du inte redan har gjort det registrerar du ett webbprogram och aktiverar implicit beviljande av ID-token.

Använd Kör nu och https://jwt.ms för att testa dina principer oberoende av ditt webb- eller mobilprogram. Den här webbplatsen fungerar som en betroende partnerapplikation. Den visar innehållet i JSON-webbtoken (JWT) som din Azure AD B2C-princip genererar.

Felsöka SAML-protokoll

För att konfigurera och felsöka integreringen med tjänstleverantören kan du använda ett webbläsartillägg för SAML-protokollet, till exempel SAML DevTools-tillägget för Chrome, SAML-tracer för Firefox eller Utvecklarverktyg för Edge eller Internet Explorer.

Följande skärmbild visar hur SAML DevTools-tillägget visar SAML-begäran som Azure AD B2C skickar till identitetsprovidern och SAML-svaret.

Med de här verktygen kan du kontrollera integreringen mellan ditt program och Azure AD B2C. Till exempel:

• Kontrollera om SAML-begäran innehåller en signatur och avgör vilken algoritm som används för att logga in auktoriseringsbegäran.
• Kontrollera om Azure AD B2C returnerar ett felmeddelande.
• Kontrollera om påståendedelen är krypterad.
• Hämta namnet på anspråken som returnerar identitetsprovidern.

Du kan också spåra utbytet av meddelanden mellan klientwebbläsaren och Azure AD B2C med Fiddler. Det kan hjälpa dig att få en indikation på var din användarresa misslyckas i orkestreringsstegen.

Felsöka giltigheten för policy

När du har utvecklat principen laddar du upp principen till Azure AD B2C. Det kan finnas vissa problem med din princip, men du kan verifiera din princip innan du laddar upp den.

Det vanligaste felet vid konfiguration av anpassade principer är felaktigt formaterad XML. En bra XML-redigerare är nästan nödvändig. Den visar XML inbyggt, färgkodar innehåll, fyller i vanliga termer i förväg, håller XML-element indexerade, och kan verifiera mot ett XML-schema.

Vi rekommenderar att du använder Visual Studio Code. Installera sedan ett XML-tillägg, till exempel XML Language Support by Red Hat. XML-tillägget låter dig verifiera XML-schemat innan du laddar upp XML-filen, med hjälp av en anpassad princip för XSD-schemadefinitionen.

Du kan använda XML-filassociationsstrategin för att binda XML-filen till XSD genom att lägga till följande inställningar i VS Code-filen settings.json . Så här gör du:

1. I VS Code väljer du Fil>Preferenser>Inställningar. Mer information finns i Inställningar för användare och arbetsyta.

2. Sök efter fileAssociations och välj sedan XML under tillägget.

3. Välj Redigera i settings.json.

   

4. I settings.jsonlägger du till följande JSON-kod:

   "xml.fileAssociations": [
     {
       "pattern": "**.xml",
       "systemId": "https://raw.githubusercontent.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/master/TrustFrameworkPolicy_0.3.0.0.xsd"
     }
   ]
   

5. Spara ändringarna.

I följande exempel visas ett XML-verifieringsfel. När du flyttar musen över elementnamnet listar tillägget de förväntade elementen.

I följande fall är elementet DisplayName korrekt. Men i fel ordning. DisplayName Ska vara före elementetProtocol. Lös problemet genom att flytta musen över elementet DisplayName till rätt ordning för elementen.

Ladda upp principer och principverifiering

Verifiering av XML-principfilen utförs automatiskt vid uppladdning. De flesta fel gör att uppladdningen misslyckas. Valideringen innehåller den principfil som du vill ladda upp. Den innehåller också filkedjan som uppladdningsfilen refererar till (den förlitande partens principfil, tilläggsfilen och basfilen).

Det här avsnittet innehåller vanliga valideringsfel och troliga lösningar.

Schemaverifieringsfel hittades ... har ett ogiltigt underordnat element '{name}'

Din policy innehåller ett ogiltigt XML-element, eller XML-elementet är giltigt, men det verkar vara i fel ordning. Om du vill åtgärda den här typen av fel kan du läsa avsnittet Felsöka policyvaliditet.

Det finns en duplicerad nyckelsekvens {number}

En användarresa eller underresa består av en ordnad lista över orkestreringssteg som körs i följd. När du har ändrat din resa numrerar du om stegen sekventiellt utan att hoppa över några heltal från 1 till N.

... förväntades ha steg med ordernumret "{number}", men kunde inte hittas...

Granska föregående fel.

Orkestreringsstegordning "{number}" i användarresan "{name}" ... följs av ett urvalssteg för anspråksprovidern och måste vara ett anspråksutbyte, men det är av typen ...

Orkestreringsstegstypen ClaimsProviderSelectionoch CombinedSignInAndSignUp innehåller en lista med alternativ som en användare kan välja mellan. Det måste följas av typen ClaimsExchange med ett eller flera utbyten av anspråk.

Följande orkestreringssteg orsakar den här typen eller felet. Det andra orkestreringssteget måste vara typen ClaimsExchange, inte ClaimsProviderSelection.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
        <ClaimsProviderSelections>
          <ClaimsProviderSelection TargetClaimsExchangeId="FacebookExchange"/>
          <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange"/>
        </ClaimsProviderSelections>
        <ClaimsExchanges>
          <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email"/>
        </ClaimsExchanges>
      </OrchestrationStep> 

      <OrchestrationStep Order="2" Type="ClaimsProviderSelection">
        ...
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

... steg {number} med 2 anspråksutbyten. Det måste föregås av ett val av anspråksleverantör för att avgöra vilket anspråksutbyte som kan användas

En orkestreringsstegtyp ClaimsExchange måste ha en enda ClaimsExchange, såvida inte föregående steg är typen ClaimsProviderSelection, eller CombinedSignInAndSignUp. Följande orkestreringssteg orsakar den här typen av fel. Det sjätte steget innehåller två anspråksutbyte.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

Använd två orkestreringssteg för att åtgärda den här typen av fel. Varje orkestreringssteg med ett anspråksutbyte.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="5" Type="ClaimsExchange">
        ...
        <ClaimsExchanges>
          <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="6" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-First-API" TechnicalProfileReferenceId="Call-REST-First-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-Second-API" TechnicalProfileReferenceId="Call-REST-Second-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

Det finns en duplicerad nyckelsekvens {name}

En resa har flera ClaimsExchange med samma Id. Följande steg orsakar den här typen av fel. ID AADUserWrite visas två gånger i användarresan.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

Om du vill åtgärda den här typen av fel ändrar du den åttonde orkestreringsstegens anspråksutbyte till ett unikt namn, till exempel Call-REST-API.

<!-- 
<UserJourneys>
  <UserJourney Id="SignUpOrSignIn">
    <OrchestrationSteps>-->
      ...
      <OrchestrationStep Order="7" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      <OrchestrationStep Order="8" Type="ClaimsExchange">
        <ClaimsExchanges>
          <ClaimsExchange Id="Call-REST-API" TechnicalProfileReferenceId="Call-REST-API"/>
        </ClaimsExchanges>
      </OrchestrationStep>
      ...
    <!--
    </OrchestrationSteps>
  </UserJourney>
</UserJourneys> -->

... refererar till ClaimType med ID :t {anspråksnamn}, men varken principen eller någon av dess basprinciper innehåller ett sådant element

Den här typen av fel inträffar när principen refererar till ett anspråk som inte deklareras i anspråksschemat. Påståenden måste definieras i minst en av filerna i policyn.

Till exempel en teknisk profil med ett utdataanspråk från schoolId. Men utdataanspråket schoolId deklareras aldrig i policyn, eller i en överordnad policy.

<OutputClaims>
  <OutputClaim ClaimTypeReferenceId="schoolId" />
  ...
</OutputClaims>

Åtgärda den här typen av fel genom att kontrollera om ClaimTypeReferenceId värdet är felstavat eller inte finns i schemat. Om anspråket definieras i utökningspolicyn, men det används också i grundpolicyn. Kontrollera att anspråket har definierats i policyn där det används eller i en policy på en högre nivå.

Att lägga till anspråket i anspråksschemat löser den här typen av fel.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="schoolId">
      <DisplayName>School name</DisplayName>
      <DataType>string</DataType>
      <UserHelpText>Enter your school name</UserHelpText>
      <UserInputType>TextBox</UserInputType>
    </ClaimType>
  <!-- 
  </ClaimsSchema>
</BuildingBlocks> -->

... refererar till en ClaimsTransformation med ID...

Orsaken till det här felet liknar den för anspråksfelet. Granska föregående fel.

Användaren är för närvarande inloggad med användarnamn för klientorganisationen "yourtenant.onmicrosoft.com" ...

Du loggar in med ett konto från en klientorganisation som är annorlunda än den policy du försöker ladda upp. Du kan till exempel logga in med admin@contoso.onmicrosoft.com, medan principen TenantId är inställd på fabrikam.onmicrosoft.com.

<TrustFrameworkPolicy ...
  TenantId="fabrikam.onmicrosoft.com"
  PolicyId="B2C_1A_signup_signin"
  PublicPolicyUri="http://fabrikam.onmicrosoft.com/B2C_1A_signup_signin">

  <BasePolicy>
    <TenantId>fabrikam.onmicrosoft.com</TenantId>
    <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
  </BasePolicy>
  ...
</TrustFrameworkPolicy>

• Kontrollera att TenantId värdet i elementen <TrustFrameworkPolicy\> och <BasePolicy\> matchar din Azure AD B2C-målklientorganisation.

Anspråkstypen {name} är utdataanspråket för den förlitande partens tekniska profil, men det är inte ett utdataanspråk i något av stegen i användarresan...

I en relying party-policy har du lagt till ett utdataanspråk, men utdataanspråket framträder inte som ett utdataanspråk i något av stegen i användarens resa. Azure AD B2C kan inte läsa anspråksvärdet från anspråkspåsen.

I följande exempel är schoolId-anspråket ett utdataanspråk för den förlitande partens tekniska profil, men det är inte ett utdataanspråk i något av stegen i SignUpOrSignIn-användarresan .

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="schoolId" />
      ...
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

För att åtgärda den här typen av fel, se till att utdataanspråk visas i minst en teknisk profils utdataanspråkssamling för orkestreringssteg. Om din användarresa inte kan mata ut anspråket anger du ett standardvärde i den förlitande partens tekniska profil, till exempel tom sträng.

<OutputClaim ClaimTypeReferenceId="schoolId" DefaultValue="" />

Indatasträngen var inte i rätt format

Du anger felaktig värdetyp till ett anspråk från en annan typ. Du kan till exempel definiera ett heltalsanspråk.

<!--
<BuildingBlocks>
  <ClaimsSchema> -->
    <ClaimType Id="age">
      <DisplayName>Age</DisplayName>
      <DataType>int</DataType>
    </ClaimType>
  <!--
  </ClaimsSchema>
</BuildingBlocks> -->

Sedan försöker du ange ett strängvärde:

<OutputClaim ClaimTypeReferenceId="age" DefaultValue="ABCD" />

Om du vill åtgärda den här typen av fel kontrollerar du att du anger rätt värde, till exempel DefaultValue="0".

Hyresgästen "{name}" har redan en policy med ID "{name}". Det går inte att spara en annan policy med samma ID

Du försöker ladda upp en princip till klientorganisationen, men en princip med samma namn har redan laddats upp till din klientorganisation.

Om du vill åtgärda den här typen av fel markerar du kryssrutan Skriv över den anpassade principen om den redan finns när du laddar upp principen.