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

Innan du börjaranvänder du väljaren Välj en principtyp för att välja den typ av princip som du ställer in. Azure Active Directory B2C erbjuder två metoder för att definiera hur användare interagerar med dina program: via fördefinierade användarflöden eller genom fullständigt konfigurerbara anpassade principer. Stegen som krävs i den här artikeln är olika för varje metod.

Programmet måste hantera vissa fel som kommer från Azure B2C-tjänsten. Den här artikeln beskriver några av de vanligaste felen och hur du hanterar dem.

Fel vid lösenordsåterställning

Det här felet uppstår när självbetjäning av lösenordsåterställning inte är aktiverat i ett användarflöde. Om du väljer länken Har du glömt ditt lösenord? utlöses därför inte användarflödet för lösenordsåterställning. I stället returneras AADB2C90118 felkoden till ditt program.

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

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 avbryt-åtgärd:

  • En användarprincip använder den rekommenderade SSPR-upplevelsen (self service password resect) med ett lokalt konsumentkonto. Användaren väljer länken Har du glömt ditt lösenord? och väljer sedan knappen Avbryt innan användarflödet slutförs. I det här Azure AD B2C returnerar tjänsten AADB2C90091 felkod till ditt program.
  • En användare väljer att autentisera med en extern identitetsprovider, till exempel LinkedIn. Användaren väljer knappen Avbryt innan autentiseringen till själva identitetsprovidern. I det här Azure AD B2C returnerar tjänsten AADB2C90273 felkod till ditt program. Läs mer om felkoder Azure Active Directory B2C-tjänsten returnerar.

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

Om du använder anpassade Azure Active Directory B2C(Azure AD B2C) kan det vara problem med XML-format eller körningsproblem med principspråket. 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å felsökning Azure AD B2C konfiguration av anpassade policyer. Den behandlar inte det förlitande partsprogrammet eller dess identitetsbibliotek.

översikt Azure AD B2C korrelations-ID

Azure AD B2C korrelations-ID ä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 ditt program och spåra principens prestanda.
  • Leta reda på inloggningsbegärans Azure Application Insights loggar.
  • Skicka korrelations-ID:t till REST API och använd det för att identifiera inloggningsflödet.

Korrelations-ID:t ändras varje gång en ny session upprättas. När du felsöker dina principer ska du se till att stänga befintliga webbläsarflikar eller öppna en ny webbläsare i privat läge.

Hämta Azure AD B2C korrelations-ID

Du hittar korrelations-ID:t Azure AD B2C sidan för registrering eller inloggning. Välj visa källa i webbläsaren. Korrelationen visas som en kommentar överst på sidan.

Screenshot of Azure AD B2C sign-in page view source.

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.

Eko av Azure AD B2C korrelations-ID

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

  1. Öppna tilläggsfilen för principen. 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 till elementet ClaimsSchema.

    <!-- 
    <BuildingBlocks>
      <ClaimsSchema> -->
        <ClaimType Id="correlationId">
          <DisplayName>correlation ID</DisplayName>
          <DataType>string</DataType>
        </ClaimType>
      <!-- 
      </ClaimsSchema>
    </BuildingBlocks>-->
    
  5. Öppna den förlitande partfilen för principen. Till exempel SocialAndLocalAccounts/SignUpOrSignIn.xml fil. Utgående anspråk läggs till i token efter en lyckad användarresa och skickas till programmet. Ändra elementet teknisk profil i avsnittet förlitande part för att lägga till som correlationId ett utgående ansprå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öka med Application Insights

Om du vill diagnostisera problem med dina anpassade principer använder du Application Insights. Program Insights spårar aktiviteten för din anpassade princips användarresa. Det är ett sätt att diagnostisera undantag och observera utbyte av anspråk mellan Azure AD B2C och de olika anspråksproviders som definieras av tekniska profiler, till exempel identitetsproviders, API-baserade tjänster, Azure AD B2C-användarkatalogen och andra tjänster.

Vi rekommenderar att du 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 den körs av Azure AD B2C.

Anteckning

  • Det finns en kort fördröjning, vanligtvis mindre än fem minuter, innan du kan se nya loggar i Application Insights.
  • Communityn har utvecklat tillägget Visual Studio Code för Azure AD B2C för att hjälpa identitetsutvecklare. Tillägget stöds inte av Microsoft och görs endast tillgängligt i den utsträckning som det är.

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

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

Screenshot of Azure AD B2C extension for VS Code with Azure Application Insights trace.

Filtrera spårningsloggen

Med fokus på spårningsutforskaren Azure AD B2C du börja 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 markeras.

Screenshot of Azure AD B2C extension Azure AD B2C trace explorer filter highlighting.

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

Screenshot of Azure AD B2C extension Azure AD B2C trace explorer filter.

Information Insights spårningslogg för program

När du väljer Azure Application Insights en spårning öppnar tillägget fönstret Application Insights details (Programinformation) med följande information:

  • Program 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 ett förhandsvillkor 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.
  • Omvandling av anspråk – Lista över anspråksomvandlare som visas i spårningsloggen. Varje anspråksomvandling innehåller inkommande anspråk, indataparametrar och utgående anspråk. Avsnittet om anspråksomvandling ger insikt i de data som skickas i och resultatet av anspråksomvandlingen.
  • Token – Lista över token som visas i spårningsloggen. Token inkluderar den underliggande federerade OAuth och OpenId Anslut för identitetsproviderns token. Den federerade identitetsproviderns token ger information om hur identitetsprovidern returnerar anspråken till Azure AD B2C så att du kan mappa utgående ansprå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å fönstret Application Insights trace log details (Information om programspårningslogg).

Screenshot of Azure AD B2C extension Azure AD B2C trace report.

Felsöka JWT-token

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

Screenshot of JWT token preview.

Använd Kör nu och för att testa dina principer oberoende av ditt webb- eller mobilprogram. Den här webbplatsen fungerar som ett förlitande partsprogram. Den visar innehållet i JSON-webbtoken (JWT) som genereras av din Azure AD B2C princip.

Felsöka SAML-protokoll

För att konfigurera och felsöka integreringen med din tjänstleverantör 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 Edge eller IE Utvecklarverktyg.

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

Screenshot of SAML protocol trace log.

Med hjälp av dessa verktyg kan du kontrollera integreringen mellan ditt program och Azure AD B2C. Ett 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 kontrollavsnittet är krypterat.
  • Hämta namnet på anspråken som returnerar identitetsprovidern.

Du kan också spåra utbyte av meddelanden mellan klientens webbläsare 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 principens giltighet

När du har utvecklat principen laddar du upp den till Azure AD B2C. det kan finnas problem med principen. Använd följande metoder för att säkerställa din principintegritet/giltighet.

Det vanligaste felet vid inställning av anpassade principer är felaktigt formaterad XML. En bra XML-redigerare är nästan nödvändig. Den visar XML-innehåll med färgkoder, fyller i vanliga termer i förväg, behåller XML-element som indexeras och kan validera 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. Med XML-tillägget kan du verifiera XML-schemat innan du laddar upp XML-filen med hjälp av XSD-schemadefinitionen för anpassade policyer.

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

  1. Från VS Code klickar du på Inställningar. Mer information finns i User and Workspace Inställningar.

  2. Sök efter fileAssociationsoch välj SEDANXML under Tillägget.

  3. Välj Redigera i settings.json.

    Screenshot of VS Code XML schema validation.

  4. Lägg till följande JSON-kod i settings.json:

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

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

Screenshot of VS Code XML schema validation error indicator.

I följande fall är DisplayName elementet korrekt. Men i fel ordning. DisplayNameska vara före elementet Protocol . Du kan åtgärda problemet genom att flytta musen över DisplayName elementet till rätt ordning för elementen.

Screenshot of VS Code XML schema validation order error.

Upload principer och principvalidering

Verifiering av XML-principfilen utförs automatiskt vid uppladdning. De flesta fel gör att uppladdningen misslyckas. Verifieringen innehåller principfilen som du laddar upp. Den innehåller också den filkedja som uppladdningsfilen refererar till (principfilen för förlitande part, filtillägget och basfilen).

Tips

Azure AD B2C kör ytterligare validering för förlitande partsprincip. När du har problem med principen, även om du bara redigerar tilläggsprincipen, är det en bra idé att ladda upp principen för förlitande part också.

Det här avsnittet innehåller vanliga verifieringsfel och sannolika lösningar.

Schemavalideringsfel hittades ... har ogiltigt underdelselement "{name}"

Principen innehåller ett ogiltigt XML-element, eller så är XML-elementet giltigt, men verkar vara i fel ordning. Information om hur du åtgärdar den här typen av fel finns i avsnittet Felsöka giltighet för princip.

Det finns en dubblettnyckelsekvens "{number}"

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

Tips

Du kan använda Azure AD B2C förVS Code-kommandot för att numrera om alla användarresor och orkestreringssteg för underresor i principen.

... förväntades ha steg med ordern "{number}" men hittades inte...

Kontrollera 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 ...

Orkestreringsstegtypen ClaimsProviderSelection och innehåller en lista med alternativ som en användare kan välja CombinedSignInAndSignUp mellan. Den måste följa efter typ av ClaimsExchange med ett eller flera anspråksutbyte.

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

Orkestreringsstegtypen ClaimsExchange måste ha en enda , såvida inte föregående steg är av typen eller ClaimsExchangeClaimsProviderSelectionCombinedSignInAndSignUp . 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 ClaimsExchange flera med samma Id . Följande steg orsakar den här typen av fel. ID:t AADUserWrite visas två gånger under 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> -->

Du kan åtgärda den här typen av fel genom att ändra anspråksutbytet i de åttonde orkestreringsstegen 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 "{claim name}" men varken principen eller dess basprinciper innehåller ett sådant element

Den här typen av fel inträffar när principen gör en referens till ett anspråk som inte har deklarerats i anspråksschemat. Anspråk måste definieras i minst en av filerna i principen.

Till exempel en teknisk profil med utdataanspråket schoolId. Men det utgående anspråket schoolId deklareras aldrig i principen eller i en överordnad princip.

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

Du kan åtgärda den här typen av fel genom att kontrollera om värdet ClaimTypeReferenceId är felstavat eller inte finns i schemat. Om anspråket definieras i tilläggsprincipen, men det också används i basprincipen. Kontrollera att anspråket har definierats i den princip som det används i, eller i en princip på den övre nivån.

Den här typen av fel löss genom att anspråket läggs till i anspråksschemat.

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

... gör en referens till en ClaimsTransformation med ID...

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

Användaren är för närvarande inloggad som användare av klientorganisationen "yourtenant.onmicrosoft.com" ...

Du loggar in med ett konto från en klientorganisation som skiljer sig från den princip som du försöker ladda upp. Till exempel din inloggning med admin@contoso.onmicrosoft.com , medan principen är inställd på TenantIdfabrikam.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 värdet TenantId i elementen <TrustFrameworkPolicy\> och matchar Azure AD B2C <BasePolicy\> klientorganisationen.

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

I en princip för förlitande part har du lagt till ett utgående anspråk, men utgående anspråk är inte ett utgående anspråk i något av stegen i användarresan. Azure AD B2C kan inte läsa anspråksvärdet från anspråksdepån.

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

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

Om du vill åtgärda den här typen av fel kontrollerar du att utgående anspråk visas i minst ett orkestreringsstegs samling tekniska profilutdataanspråk. Om din användarresa inte kan mata ut anspråket anger du ett standardvärde i den förlitande partens tekniska profil, till exempel en tom sträng.

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

Indatasträngen hade inte 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" .

Klientorganisationen "{name}" har redan en princip med ID:t "{name}". En annan princip med samma ID kan inte lagras

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

Du kan åtgärda den här typen av fel genom att markera kryssrutan Skriv över den anpassade principen om den redan finns när du laddar upp principen.

Screenshot that demonstrates how to overwrite the custom policy if it already exists.

Nästa steg