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

Przed rozpoczęciem użyj selektora Wybierz typ zasad, aby wybrać typ konfigurowanych zasad. Usługa Azure Active Directory B2C oferuje dwie metody definiowania sposobu interakcji użytkowników z aplikacjami: za pomocą wstępnie zdefiniowanych przepływów użytkowników lub w pełni konfigurowalnych zasad niestandardowych. Kroki wymagane w tym artykule są różne dla każdej metody.

Aplikacja musi obsługiwać niektóre błędy pochodzące z usługi Azure B2C. W tym artykule przedstawiono niektóre typowe błędy i sposób ich obsługi.

Błąd resetowania hasła

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

Istnieje 2 rozwiązania tego problemu:

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 środowiska samoobsługowego resetowania hasła (SSPR) z kontem lokalnym użytkownika. Użytkownik wybierze link Nie pamiętasz hasła? i wybierze przycisk Anuluj przed zakończeniem przepływu użytkownika. 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 wybierz przycisk Anuluj przed uwierzytelnieniem 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 z powrotem przy użyciu nowego żądania uwierzytelniania przy użyciu 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 to unikatowa wartość identyfikatora dołączona do żądań autoryzacji. Przechodzi on przez wszystkie kroki orkiestracji, przez które przechodzi użytkownik. Za pomocą identyfikatora korelacji można wykonywać następujące czynności:

  • Zidentyfikuj aktywność logowania w aplikacji i śledź wydajność zasad.
  • Znajdź dzienniki aplikacja systemu Azure Szczegółowe informacje żądania logowania.
  • 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

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.

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

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 Szczegółowe informacje aplikacji.

Echo 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 jednostki uzależnionej zasad. 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 Szczegółowe informacje aplikacji

Aby zdiagnozować problemy z zasadami niestandardowymi, użyj Szczegółowe informacje aplikacji. Aplikacja Szczegółowe informacje śledzi aktywność użytkownika zasad niestandardowych. 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. Dzięki rozszerzeniu usługi Azure AD B2C dzienniki są zorganizowane według nazwy zasad, identyfikatora korelacji (aplikacja Szczegółowe informacje przedstawia pierwszą cyfrę identyfikatora korelacji) i znacznik czasu dziennika. Ta funkcja pomaga znaleźć odpowiedni dziennik na podstawie lokalnego znacznika czasu i zobaczyć podróż użytkownika zgodnie z wykonaniem przez usługę Azure AD B2C.

Uwaga

  • Istnieje krótkie opóźnienie, zazwyczaj krótsze niż pięć minut, zanim będzie można zobaczyć nowe dzienniki w aplikacji Szczegółowe informacje.
  • Społeczność opracowała rozszerzenie programu Visual Studio Code dla usługi Azure AD B2C, aby pomóc deweloperom tożsamości. Rozszerzenie nie jest obsługiwane przez firmę Microsoft i jest udostępniane ściśle zgodnie z rzeczywistymi wersjami.

Przepływ logowania jednokrotnego może wystawiać więcej niż jeden ślad aplikacja systemu Azure Szczegółowe informacje. Na poniższym zrzucie ekranu zasady B2C_1A_signup_signin mają trzy dzienniki. Każdy dziennik reprezentuje część przepływu logowania.

Poniższy zrzut ekranu przedstawia rozszerzenie usługi Azure AD B2C dla programu VS Code z eksploratorem śledzenia aplikacja systemu Azure Szczegółowe informacje.

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

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.

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

Umieszczenie kursora nad polem filtru i wybranie pozycji Włącz filtr w typie spowoduje wyświetlenie tylko pasujących dzienników śledzenia. Użyj przycisku Wyczyść "X", aby wyczyścić filtr.

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

Szczegóły dziennika śledzenia Szczegółowe informacje aplikacji

Po wybraniu śledzenia aplikacja systemu Azure Szczegółowe informacje rozszerzenie otwiera okno Szczegóły Szczegółowe informacje aplikacji z następującymi informacjami:

  • Szczegółowe informacje aplikacji — ogólne informacje o dzienniku śledzenia, w tym nazwy zasad, identyfikatora korelacji, identyfikatora aplikacja systemu Azure Szczegółowe informacje identyfikatora śledzenia i znacznika 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.
  • Przekształcanie oświadczeń — lista przekształceń oświadczeń, 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 uwierzytelnianie OAuth i tokeny dostawcy tożsamości OpenId Połączenie. 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.
  • Application Szczegółowe informacje JSON — nieprzetworzone dane zwracane z Szczegółowe informacje aplikacji.

Poniższy zrzut ekranu przedstawia przykład okna Szczegóły dziennika śledzenia aplikacji Szczegółowe informacje.

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

Rozwiązywanie problemów z tokenami JWT

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

Screenshot of JWT token preview.

Użyj polecenia 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 on zawartość tokenu internetowego JSON (JWT), który generuje zasady usługi 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 firefox lub przeglądarki Edge lub Narzędzia programistyczne IE.

Poniższy zrzut ekranu przedstawia sposób, w jaki rozszerzenie SAML DevTools przedstawia żądanie SAML wysyłane do dostawcy tożsamości i odpowiedzi SAML.

Screenshot of SAML protocol trace log.

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 poznać miejsce, w którym podróż użytkownika kończy się niepowodzeniem w krokach aranżacji.

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 zasadami, ale przed przekazaniem zasad można je ważność.

Najczęstszym błędem podczas konfigurowania zasad niestandardowych jest niepoprawnie sformatowany kod XML. Dobry edytor XML jest prawie niezbędny. Wyświetla kod XML natywnie, zawartość kodów kolorów, wstępnie wypełnia typowe terminy, przechowuje indeksowane elementy XML i może weryfikować względem schematu 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 umożliwia zweryfikowanie schematu XML przed przekazaniem pliku XML przy użyciu niestandardowej definicji schematu XSD zasad.

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

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

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

  3. Wybierz pozycję Edytuj w pliku settings.json.

    Screenshot of VS Code XML schema validation.

  4. W pliku settings.json dodaj 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.

Screenshot of VS Code XML schema validation error indicator.

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.

Screenshot of VS Code XML schema validation order error.

Przekazywanie zasad i walidacji zasad

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

Napiwek

Usługa Azure AD B2C uruchamia dodatkową walidację zasad jednostki uzależnionej. Jeśli masz problem z zasadami, nawet jeśli edytujesz tylko zasady rozszerzenia, dobrym rozwiązaniem jest przekazanie zasad jednostki uzależnionej.

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 aranżacji, które są wykonywane w sekwencji. Po zmianie podróży zmień kolejność kroków sekwencyjnie bez pomijania żadnych liczb całkowitych z zakresu od 1 do N.

Napiwek

Możesz użyć rozszerzenia Azure AD B2C dla programu VS Code(Shift+Ctrl+r) , aby zmienić numer wszystkich podróży użytkownika i pod podróży w ramach kroków aranżacji w zasadach.

... oczekiwano, że krok z kolejnością "{number}", ale nie został znaleziony...

Sprawdź poprzedni błąd.

Kolejność kroków orkiestracji "{number}" w podróży użytkownika "{name}" ... następuje krok wyboru dostawcy oświadczeń i musi być wymianą oświadczeń, ale jest to typ...

Typ ClaimsProviderSelectionkroków aranżacji i CombinedSignInAndSignUp zawiera listę opcji, które użytkownik może wybrać. Musi być zgodny z typem ClaimsExchange z co najmniej jedną wymianą oświadczeń.

Poniższe kroki aranżacji powodują ten typ lub błąd. Drugi krok aranżacji 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 oświadczeń. Należy go poprzedzić wyborem dostawcy oświadczeń, aby określić, która wymiana oświadczeń może być używana

Typ ClaimsExchange kroku aranżacji musi mieć jeden ClaimsExchangeelement , 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 Idelementem . 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ń liczbę oświadczeń ósmych kroków aranżacji 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ń. Oświadczenia muszą być zdefiniowane w co najmniej jednym z plików w zasadach.

Na przykład profil techniczny z oświadczeniem wyjściowym schoolId . Ale dane wyjściowe claim schoolId nigdy nie są deklarowane w zasadach lub w zasadach przodków.

<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 oświadczenie jest zdefiniowane w zasadach rozszerzeń, ale jest również używane 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> -->

... tworzy odwołanie 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żawy "yourtenant.onmicrosoft.com" ...

Zaloguj się przy użyciu konta z dzierżawy, która różni się od zasad, które próbujesz przekazać. Na przykład logowanie przy admin@contoso.onmicrosoft.comużyciu polecenia , a zasady TenantId są ustawione 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 TenantId wartość w elementach <TrustFrameworkPolicy\> i <BasePolicy\> jest zgodna z docelową dzierżawą usługi Azure AD B2C.

Typ oświadczenia "{name}" jest oświadczeniem wyjściowym profilu technicznego jednostki uzależnionej, ale nie jest oświadczeniem wyjściowym w żadnym kroku podróży użytkownika...

W zasadach jednostki uzależnionej dodano oświadczenie wyjściowe, ale oświadczenie wyjściowe nie jest oświadczeniem wyjściowym w żadnym z kroków podróży 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 jednostki uzależnionej, ale nie jest oświadczeniem wyjściowym w żadnej z kroków podróży 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ń wyjściowych profilu technicznego profilu technicznego. Jeśli podróż użytkownika nie może wystawić oświadczenia, w profilu technicznym jednostki uzależnionej ustaw wartość domyślną, taką jak pusty ciąg.

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

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

Ustawiasz niepoprawny typ wartości na oświadczenie z innego typu. Na przykład zdefiniujesz oświadczenie 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".

Dzierżawa "{name}" ma już zasady o identyfikatorze "{name}". Nie można przechowywać innych zasad o tym samym identyfikatorze

Spróbujesz przekazać zasady do dzierżawy, ale zasady o tej samej nazwie zostały już przekazane do dzierżawy.

Aby naprawić ten typ błędu, po przekazaniu zasad zaznacz pole wyboru Zastąp zasady niestandardowe, jeśli już istnieje .

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

Następne kroki