Rozwiązywanie problemów z niestandardowymi zasadami i przepływami użytkowników usługi Azure AD B2C

Błąd resetowania hasła

Ten błąd występuje, gdy funkcja samoobsługowego resetowania hasła nie jest włączona w ramach procesu użytkownika. W związku z tym wybranie linku Nie pamiętasz hasła? nie powoduje wyzwolenia procesu resetowania hasła. Zamiast tego kod AADB2C90118 błędu jest zwracany do aplikacji.

Istnieje 2 rozwiązania tego problemu:

• Odpowiedz z powrotem przy użyciu nowego żądania uwierzytelniania przy użyciu przepływu użytkownika resetowania hasła usługi Azure AD B2C.
  • Użyj zalecanego doświadczenia samoobsługowego resetowania hasła (SSPR).

Użytkownik anulował operację

Usługa Azure AD B2C może również zwrócić błąd do aplikacji, gdy użytkownik anuluje operację. Poniżej przedstawiono przykłady scenariuszy, w których użytkownik wykonuje operację anulowania:

• Zasady użytkownika korzystają z zalecanego doświadczenia samoobsługowego resetowania hasła (SSPR) z lokalnym kontem konsumenckim. Użytkownik wybiera link Nie pamiętasz hasła?, a następnie wybiera przycisk Anuluj przed ukończeniem procesu. W takim przypadku usługa Azure AD B2C zwraca kod AADB2C90091 błędu do aplikacji.
• Użytkownik wybiera uwierzytelnianie za pomocą zewnętrznego dostawcy tożsamości, takiego jak LinkedIn. Użytkownik wybiera przycisk Anuluj zanim uwierzytelni się u dostawcy tożsamości. W takim przypadku usługa Azure AD B2C zwraca kod AADB2C90273 błędu do aplikacji. Dowiedz się więcej o kodach błędów zwracanych przez usługę Azure Active Directory B2C.

Aby obsłużyć ten błąd, pobierz opis błędu dla użytkownika i odpowiedz nowym żądaniem uwierzytelniania, używając tego samego przepływu użytkownika.

Jeśli używasz zasad niestandardowych usługi Azure Active Directory B2C (Azure AD B2C), mogą wystąpić problemy z formatem XML języka zasad lub środowiskiem uruchomieniowym. W tym artykule opisano niektóre narzędzia i porady, które mogą ułatwić odnajdywanie i rozwiązywanie problemów.

Ten artykuł koncentruje się na rozwiązywaniu problemów z konfiguracją zasad niestandardowych usługi Azure AD B2C. Nie dotyczy aplikacji jednostki uzależnionej ani jej biblioteki tożsamości.

Omówienie identyfikatora korelacji usługi Azure AD B2C

Identyfikator korelacji usługi Azure AD B2C jest unikatową wartością identyfikatora dołączoną do żądań autoryzacji. Przechodzi przez wszystkie etapy koordynacji, które wykonuje użytkownik. Za pomocą identyfikatora korelacji można wykonywać następujące czynności:

• Zidentyfikuj aktywność logowania w aplikacji i śledź wydajność polityki.
• Znajdź dzienniki żądania logowania usługi Azure Application Insights.
• Przekaż identyfikator korelacji do interfejsu API REST i użyj go, aby zidentyfikować przepływ logowania.

Identyfikator korelacji jest zmieniany za każdym razem, gdy zostanie ustanowiona nowa sesja. Podczas debugowania zasad upewnij się, że zamkniesz istniejące karty przeglądarki lub otworzysz nową przeglądarkę w trybie prywatnym.

Wymagania wstępne

• Wykonaj kroki opisane w Jak rozpocząć z zasadami niestandardowymi w usłudze Active Directory B2C.

Pobieranie identyfikatora korelacji usługi Azure AD B2C

Identyfikator korelacji można znaleźć na stronie rejestracji lub logowania usługi Azure AD B2C. W przeglądarce wybierz pozycję Wyświetl źródło. Korelacja jest wyświetlana jako komentarz w górnej części strony.

Skopiuj identyfikator korelacji, a następnie kontynuuj przepływ logowania. Użyj identyfikatora korelacji, aby obserwować zachowanie logowania. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z usługą Application Insights.

Wyświetl identyfikator korelacji usługi Azure AD B2C

Identyfikator korelacji można uwzględnić w tokenach usługi Azure AD B2C. Aby uwzględnić identyfikator korelacji:

1. Otwórz plik rozszerzeń zasad. Na przykład SocialAndLocalAccounts/TrustFrameworkExtensions.xml.

2. Wyszukaj element BuildingBlocks . Jeśli element nie istnieje, dodaj go.

3. Znajdź element ClaimsSchema . Jeśli element nie istnieje, dodaj go.

4. Dodaj oświadczenie identyfikatora korelacji do elementu ClaimsSchema .

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

5. Otwórz plik uczestnika zaufania swojej polityki. Na przykład SocialAndLocalAccounts/SignUpOrSignIn.xml plik. Oświadczenie wyjściowe zostanie dodane do tokenu po pomyślnej podróży użytkownika i wysłane do aplikacji. Zmodyfikuj element profilu technicznego w sekcji jednostki uzależnionej, aby dodać correlationId element jako oświadczenie wyjściowe.

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

Rozwiązywanie problemów z usługą Application Insights

Aby zdiagnozować problemy z zasadami niestandardowymi, użyj usługi Application Insights. Application Insights śledzi przebieg aktywności użytkownika w ramach niestandardowych zasad. Umożliwia diagnozowanie wyjątków i obserwowanie wymiany oświadczeń między usługą Azure AD B2C a różnymi dostawcami oświadczeń. Dostawcy oświadczeń są definiowani przez profile techniczne, takie jak dostawcy tożsamości, usługi oparte na interfejsie API, katalog użytkowników usługi Azure AD B2C i inne usługi.

Zalecamy zainstalowanie rozszerzenia usługi Azure AD B2C dla programu VS Code. W przypadku rozszerzenia usługi Azure AD B2C dzienniki są zorganizowane według nazwy zasad, identyfikatora korelacji (usługa Application Insights przedstawia pierwszą cyfrę identyfikatora korelacji) i sygnaturę czasową dziennika. Ta funkcja pomaga znaleźć odpowiedni dziennik na podstawie lokalnego znacznika czasu i śledzić ścieżkę użytkownika, jak została zrealizowana przez Azure AD B2C.

Jednokrotne logowanie może generować więcej niż jeden ślad w usłudze Azure Application Insights. Na poniższym zrzucie ekranu zasada B2C_1A_signup_signin ma trzy dzienniki. Każdy log reprezentuje część przepływu logowania.

Poniższy zrzut ekranu przedstawia rozszerzenie usługi Azure AD B2C dla programu VS Code z eksploratorem śledzenia usługi Azure Application Insights.

Filtrowanie dziennika śledzenia

Koncentrując się na eksploratorze śledzenia usługi Azure AD B2C, zacznij wpisywać pierwszą cyfrę identyfikatora korelacji lub czas, który chcesz znaleźć. W prawym górnym rogu eksploratora śledzenia usługi Azure AD B2C zostanie wyświetlone pole filtru pokazujące, co zostało wpisane do tej pory, a pasujące dzienniki śledzenia są wyróżnione.

Najechanie kursorem na pole filtru i wybranie opcji Włącz filtrowanie według typu spowoduje wyświetlenie tylko odpowiadających dzienników śledzenia. Użyj przycisku Wyczyść "X" , aby wyczyścić filtr.

Zrzut ekranu przedstawiający filtr eksploratora śledzenia rozszerzenia Azure AD B2C.

Szczegóły dziennika śledzenia usługi Application Insights

Po wybraniu śledzenia usługi Azure Application Insights rozszerzenie otwiera okno szczegóły usługi Application Insights z następującymi informacjami:

• Application Insights — ogólne informacje o dzienniku śledzenia, w tym nazwę zasad, identyfikator korelacji, identyfikator śledzenia usługi Azure Application Insights i znacznik czasu śledzenia.
• Profile techniczne — lista profilów technicznych wyświetlanych w dzienniku śledzenia.
• Oświadczenia — alfabetyczna lista oświadczeń, które są wyświetlane w dzienniku śledzenia i ich wartości. Jeśli oświadczenie pojawia się w dzienniku śledzenia wiele razy z różnymi wartościami, => znak wyznacza najnowszą wartość. Możesz przejrzeć te oświadczenia, aby określić, czy oczekiwane wartości oświadczeń są ustawione poprawnie. Jeśli na przykład masz warunek wstępny sprawdzający wartość oświadczenia, sekcja oświadczeń może pomóc w ustaleniu, dlaczego oczekiwany przepływ zachowuje się inaczej.
• Transformacja roszczeń — lista przekształceń roszczeń, które są wyświetlane w dzienniku śledzenia. Każde przekształcenie oświadczeń zawiera oświadczenia wejściowe, parametry wejściowe i oświadczenia wyjściowe. Sekcja przekształcania oświadczeń zapewnia wgląd w dane wysyłane i wynik przekształcenia oświadczeń.
• Tokeny — lista tokenów wyświetlanych w dzienniku śledzenia. Tokeny obejmują podstawowe federacyjne tokeny OAuth oraz tokeny dostawcy tożsamości OpenId Connect. Token dostawcy tożsamości federacyjnej zawiera szczegółowe informacje na temat sposobu, w jaki dostawca tożsamości zwraca oświadczenia do usługi Azure AD B2C, dzięki czemu można mapować oświadczenia wyjściowe profilu technicznego dostawcy tożsamości.
• Wyjątki — lista wyjątków lub błędów krytycznych wyświetlanych w dzienniku śledzenia.
• Kod JSON usługi Application Insights — nieprzetworzone dane zwracane z usługi Application Insights.

Poniższy zrzut ekranu przedstawia przykład okna szczegółów dziennika śledzenia usługi Application Insights.

Rozwiązywanie problemów z JWTs

Na potrzeby walidacji i debugowania JWT można dekodować JWTs przy użyciu witryny, takiej jak https://jwt.ms. Utwórz aplikację testową, która może zostać przekierowana do https://jwt.ms w celu inspekcji tokenów. Jeśli jeszcze tego nie zrobiono, zarejestruj aplikację internetową i włącz niejawne przyznanie tokenu identyfikatora.

Użyj Uruchom teraz i https://jwt.ms, aby przetestować zasady niezależnie od aplikacji internetowej lub mobilnej. Ta witryna internetowa działa jak aplikacja jednostki uzależnionej. Wyświetla zawartość tokenu sieciowego JSON (JWT), który generuje polityka Azure AD B2C.

Rozwiązywanie problemów z protokołem SAML

Aby ułatwić konfigurowanie i debugowanie integracji z dostawcą usług, możesz użyć rozszerzenia przeglądarki dla protokołu SAML, na przykład rozszerzenia SAML DevTools dla programu Chrome, narzędzia SAML-tracer dla przeglądarki Firefox, przeglądarki Edge lub narzędzi deweloperskich programu Internet Explorer.

Poniższy zrzut ekranu demonstruje, w jaki sposób rozszerzenie SAML DevTools przedstawia żądanie SAML, które Azure AD B2C przesyła do dostawcy tożsamości, oraz odpowiedź SAML.

Za pomocą tych narzędzi możesz sprawdzić integrację aplikacji z usługą Azure AD B2C. Na przykład:

• Sprawdź, czy żądanie SAML zawiera podpis i określ, jaki algorytm jest używany do logowania się do żądania autoryzacji.
• Sprawdź, czy usługa Azure AD B2C zwraca komunikat o błędzie.
• Sprawdź, czy sekcja asercji jest zaszyfrowana.
• Pobierz nazwę oświadczeń, aby zwrócić dostawcę tożsamości.

Możesz również śledzić wymianę komunikatów między przeglądarką klienta i usługą Azure AD B2C za pomocą programu Fiddler. Może to pomóc w zidentyfikowaniu, gdzie twoja ścieżka użytkownika kończy się niepowodzeniem w krokach koordynacji.

Rozwiązywanie problemów z ważnością zasad

Po zakończeniu tworzenia zasad należy przekazać zasady do usługi Azure AD B2C. Mogą wystąpić pewne problemy z twoją polityką, ale możesz ją zweryfikować przed jej przesłaniem.

Najczęstszym błędem podczas konfigurowania zasad niestandardowych jest niepoprawnie sformatowany kod XML. Dobry edytor XML jest prawie niezbędny. Wyświetla kod XML w sposób natywny, koloruje zawartość, automatycznie uzupełnia typowe terminy, utrzymuje elementy XML uporządkowane według indeksów i może weryfikować zgodnie ze schematem XML.

Zalecamy używanie programu Visual Studio Code. Następnie zainstaluj rozszerzenie XML, takie jak obsługa języka XML przez firmę Red Hat. Rozszerzenie XML pozwala na weryfikację schematu XML przed przesłaniem pliku XML, używając niestandardowej definicji schematu XSD zasad.

Można użyć strategii skojarzenia plików XML, aby powiązać plik XML z XSD, dodając następujące ustawienia do pliku programu VS Code settings.json. Aby to zrobić:

1. W programie VS Code wybierz pozycję Ustawienia preferencji>plików>. Aby uzyskać więcej informacji, zobacz Ustawienia użytkownika i obszaru roboczego.

2. Wyszukaj fileAssociations, a następnie w obszarze Rozszerzenie wybierz XML.

3. Wybierz Edytuj w settings.json.

   

4. W settings.jsondodaj następujący kod 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"
     }
   ]
   

5. Zapisz zmiany.

W poniższym przykładzie przedstawiono błąd weryfikacji XML. Po przeniesieniu myszy nad nazwą elementu rozszerzenie wyświetli listę oczekiwanych elementów.

W poniższym przypadku DisplayName element jest poprawny. Ale w niewłaściwej kolejności. Element DisplayName powinien znajdować się przed elementem Protocol . Aby rozwiązać ten problem, przenieś wskaźnik myszy nad DisplayName elementem do prawidłowej kolejności elementów.

Wgrywanie zasady i walidacja polityki

Walidacja pliku zasad XML jest wykonywana automatycznie podczas przesyłania. Większość błędów powoduje niepowodzenie przesyłania. Walidacja obejmuje plik zasad, który chcesz przekazać. ** Zawiera również łańcuch plików, do których odwołuje się plik przesyłany (plik polityki zaufanej jednostki, plik rozszerzeń i plik bazowy).

Ta sekcja zawiera typowe błędy walidacji i prawdopodobne rozwiązania.

Znaleziono błąd sprawdzania poprawności schematu... ma nieprawidłowy element podrzędny "{name}"

Zasady zawierają nieprawidłowy element XML lub element XML jest prawidłowy, ale wydaje się być w niewłaściwej kolejności. Aby naprawić ten typ błędu, zapoznaj się z sekcją Rozwiązywanie problemów z ważnością zasad .

Istnieje zduplikowana sekwencja kluczy "{number}"

Podróż użytkownika lub podróż podrzędna składa się z uporządkowanej listy kroków orkiestracji, które są wykonywane w ustalonej kolejności. Po zmianie podróży ponumeruj kroki na nowo w sposób sekwencyjny, bez pomijania żadnych liczb całkowitych z zakresu od 1 do N.

... oczekiwano, że będzie krok o numerze "{number}", ale nie został znaleziony...

Sprawdź poprzedni błąd.

Kolejność kroków orkiestracji "{number}" w podróży użytkownika "{name}" ... poprzedza etap wyboru dostawcy oświadczeń i musi być wymianą oświadczeń, ale jest typu...

Typ kroków orkiestracji ClaimsProviderSelection i CombinedSignInAndSignUp zawiera listę opcji, które użytkownik może wybrać. Musi być zgodne z typem ClaimsExchange, z co najmniej jedną wymianą roszczeń.

Następujące kroki orkiestracji powodują ten rodzaj błędu. Drugi krok orkiestracji musi być typem ClaimsExchange, a nie 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> -->

... krok {number} z 2 wymianami roszczeń. Należy go poprzedzić wyborem dostawcy oświadczeń, aby określić, która wymiana oświadczeń może być używana

Typ kroku aranżacji ClaimsExchange musi mieć jeden ClaimsExchange, chyba że poprzedni krok jest typem ClaimsProviderSelection lub CombinedSignInAndSignUp. Poniższe kroki orkiestracji powodują ten typ błędu. Szósty krok zawiera dwie wymiany oświadczeń.

<!-- 
<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> -->

Aby naprawić ten typ błędu, wykonaj dwa kroki orkiestracji. Każdy krok aranżacji z jedną wymianą oświadczeń.

<!-- 
<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> -->

Istnieje zduplikowana sekwencja kluczy "{name}"

Podróż ma wiele ClaimsExchange z tym samym Id. Poniższe kroki powodują ten typ błędu. Identyfikator AADUserWrite pojawia się dwa razy w podróży użytkownika.

<!-- 
<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> -->

Aby naprawić ten typ błędu, zmień wymianę oświadczeń w ósmych krokach orkiestracji na unikatową nazwę, taką jak 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> -->

... tworzy odwołanie do obiektu ClaimType o identyfikatorze "{claim name}", ale ani zasady, ani żadne z jego zasad podstawowych nie zawierają takiego elementu

Ten typ błędu występuje, gdy zasady odwołują się do oświadczenia, które nie jest zadeklarowane w schemacie oświadczeń. Roszczenia muszą być zdefiniowane w co najmniej jednym z plików w polityce.

Na przykład profil techniczny z atrybutem wychodzącym schoolId. Jednak roszczenie wyjściowe schoolId nigdy nie jest deklarowane ani w zasadach, ani w zasadach nadrzędnych.

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

Aby naprawić ten typ błędu, sprawdź, czy ClaimTypeReferenceId wartość jest błędnie wpisana, czy nie istnieje w schemacie. Jeśli żądanie jest zdefiniowane w zasadach rozszerzeń, ale jest także stosowane w zasadach podstawowych. Upewnij się, że oświadczenie jest zdefiniowane w zasadach używanych w systemie lub w zasadach wyższego poziomu.

Dodanie oświadczenia do schematu oświadczeń rozwiązuje ten typ błędu.

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

... odnosi się do obiektu ClaimsTransformation o identyfikatorze...

Przyczyna tego błędu jest podobna do przyczyny błędu oświadczenia. Sprawdź poprzedni błąd.

Użytkownik jest obecnie zalogowany jako użytkownik dzierżawcy "yourtenant.onmicrosoft.com"...

Logujesz się kontem z dzierżawcy, który różni się od polityki, którą próbujesz przesłać. Na przykład logowanie za pomocą admin@contoso.onmicrosoft.com, a polityka TenantId jest ustawiona na 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>

• Sprawdź, czy wartość TenantId w elementach <TrustFrameworkPolicy\> i <BasePolicy\> odpowiada docelowemu dzierżawcy usługi Azure AD B2C.

Typ oświadczenia "{name}" jest oświadczeniem wyjściowym w profilu technicznym strony polegającej, ale nie jest oświadczeniem wyjściowym w żadnym kroku podróży użytkownika...

W zasadach strony korzystającej dodano oświadczenie wyjściowe, ale nie jest ono oświadczeniem wyjściowym w żadnym z kroków ścieżki użytkownika. Usługa Azure AD B2C nie może odczytać wartości oświadczenia z torby oświadczeń.

W poniższym przykładzie oświadczenie schoolId jest oświadczeniem wyjściowym profilu technicznego strony zaufanej, ale nie jest oświadczeniem wyjściowym w żadnym z kroków ścieżki użytkownika SignUpOrSignIn.

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

Aby naprawić ten typ błędu, upewnij się, że oświadczenia wyjściowe są wyświetlane w co najmniej jednej kolekcji oświadczeń końcowych profilu technicznego w etapach orkiestracji. Jeśli ścieżka użytkownika nie może wygenerować oświadczenia, w profilu technicznym strony polegającej ustaw domyślną wartość, na przykład pusty ciąg znaków.

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

Ciąg wejściowy nie był w poprawnym formacie

Ustawiłeś niepoprawny typ wartości dla roszczenia innego typu. Na przykład definiujesz roszczenie liczby całkowitej.

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

Następnie spróbujesz ustawić wartość ciągu:

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

Aby naprawić ten typ błędu, upewnij się, że ustawiono poprawną wartość, na przykład DefaultValue="0".

Najemca "{name}" ma już polisę o identyfikatorze "{name}". Nie można przechowywać innych zasad o tym samym identyfikatorze

Próbujesz przesłać polisę do swojej dzierżawy, ale polisa o tej samej nazwie została już przesłana.

Aby naprawić ten typ błędu, podczas przekazywania zasad zaznacz pole wyboru Zastąp te zasady niestandardowe, jeśli już istnieją.