Konfigurieren von xID mit Azure Active Directory B2C für die kennwortlose Authentifizierung

2025-05-06

Von Bedeutung

Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.

In diesem Lernprogramm erfahren Sie, wie Sie die Azure Active Directory B2C(Azure AD B2C)-Authentifizierung in die digitale xID-ID-Lösung integrieren. Die xID-App bietet Benutzern kennwortlose, sichere, mehrstufige Authentifizierung. Die My Number Card, die digitale ID-Karte, die von der japanischen Regierung ausgestellt wurde, überprüft xID-authentifizierte Benutzeridentitäten. Für ihre Benutzer können Organisationen überprüfte persönliche Identifikationsinformationen (Kundeninhalte) über die xID-API abrufen. Darüber hinaus generiert die xID-App einen privaten Schlüssel in einem sicheren Bereich auf mobilen Benutzergeräten, wodurch sie digitale Signaturgeräte erstellen.

Voraussetzungen

Ein Azure-Abonnement
- Wenn Sie kein Konto haben, können Sie ein kostenloses Azure-Konto erhalten.
Ein Azure AD B2C-Mandant, der mit dem Azure-Abonnement verknüpft ist
- Weitere Informationen finden Sie unter Tutorial: Erstellen eines Azure Active Directory B2C-Mandanten.
Ihre xID-Clientinformationen, die von xID inc. bereitgestellt werden.
Wechseln Sie zur Xid.inc Kontakt-Seite für xID-Clientinformationen:
- Kunden-ID
- Geheimer Clientschlüssel
- Umleitungs-URL
- Geltungsbereiche
Wechseln Sie zu x-id.me, um die xID-App auf einem mobilen Gerät zu installieren:
- Meine Nummernkarte
- Wenn Sie die API-UAT-Version nutzen, besorgen Sie sich die xID-App-UAT-Version. Siehe, Kontaktieren Sie uns

Szenariobeschreibung

Das folgende Diagramm zeigt die Architektur.

Diagramm der xID-Architektur.

Auf der Azure AD B2C-Anmeldeseite meldet sich der Benutzer an oder registriert sich.
Azure AD B2C leitet den Benutzer mithilfe einer OpenID Connect(OIDC)-Anforderung an den xID-Autorisierungs-API-Endpunkt um. Ein OIDC-Endpunkt verfügt über Endpunktinformationen. Der xID-Identitätsanbieter (IdP) leitet den Benutzer zur XID-Autorisierungsanmeldungsseite um. Der Benutzer gibt die E-Mail-Adresse ein.
xID IdP sendet Pushbenachrichtigungen an mobile Benutzergeräte.
Der Benutzer öffnet die xID-App, überprüft die Anforderung, gibt eine PIN ein oder verwendet biometrische Daten. Die xID-App aktiviert den privaten Schlüssel und erstellt eine elektronische Signatur.
Die xID-App sendet die Signatur zur Überprüfung an xID IdP.
Ein Zustimmungsbildschirm wird angezeigt, um dem Dienst persönliche Informationen zu geben.
xID IdP gibt den OAuth-Autorisierungscode an Azure AD B2C zurück.
Azure AD B2C sendet eine Tokenanforderung mithilfe des Autorisierungscodes.
xID IdP überprüft die Tokenanforderung. Wenn gültig, wird das OAuth-Zugriffstoken und das ID-Token mit Benutzer-ID und E-Mail-Adresse zurückgegeben.
Wenn Benutzerkundeninhalte benötigt werden, ruft Azure AD B2C die xID-Benutzerdaten-API auf.
Die xID-Benutzerdaten-API gibt verschlüsselten Kundeninhalt zurück. Benutzer entschlüsseln mit einem privaten Schlüssel, der beim Anfordern von xID-Clientinformationen erstellt wurde.
Dem Benutzer wird der Zugriff auf die Kundenanwendung gewährt oder verweigert.

Installieren von xID

Um API-Dokumente anzufordern, füllen Sie das Anforderungsformular aus. Gehen Sie zu Kontaktieren Sie uns.
Geben Sie in der Nachricht an, dass Sie Azure AD B2C verwenden.
Ein xID-Vertriebsmitarbeiter kontaktiert Sie.
Folgen Sie den Anweisungen im xID-API-Dokument.
Fordern Sie einen xID-API-Client an.
Das xID-Tech-Team sendet Kundeninformationen an Sie in 3-4 Werktagen.
Geben Sie einen Umleitungs-URI in Ihrer Website mithilfe des folgenden Musters an. Benutzer kehren nach der Authentifizierung dorthin zurück.

https://<your-b2c-domain>.b2clogin.com/<your-b2c-domain>.onmicrosoft.com/oauth2/authresp

Registrieren einer Webanwendung in Azure AD B2C

Registrieren Sie Anwendungen in einem von Ihnen verwalteten Mandanten, und sie können mit Azure AD B2C interagieren.

Weitere Informationen: Anwendungstypen, die in Active Directory B2C verwendet werden können

Zum Testen registrieren https://jwt.msSie eine Microsoft-Webanwendung mit decodierten Tokeninhalten, die Ihren Browser nicht verlassen.

Registrieren einer Webanwendung

Führen Sie die Schritte im Artikel Lernprogramm: Registrieren einer Webanwendung in Azure Active Directory B2C aus.

Einen xID-Richtlinienschlüssel erstellen

Speichern Sie den geheimen Clientschlüssel von xID in Ihrem Azure AD B2C-Mandanten. Verwenden Sie für die folgenden Anweisungen das Verzeichnis mit dem Azure AD B2C-Mandanten.

Melden Sie sich beim Azure-Portal an.
Wählen Sie auf der Portalsymbolleiste "Verzeichnisse + Abonnements" aus.
In den Portaleinstellungen | Seite "Verzeichnisse + Abonnements " in der Verzeichnisnamenliste nach Ihrem Azure AD B2C-Verzeichnis suchen.
Wählen Sie Wechseln aus.
Wählen Sie in der oberen linken Ecke des Azure-Portals "Alle Dienste" aus.
Suchen Sie nach Azure AD B2C, und wählen Sie es aus.
Wählen Sie im Überblickdas Identity Experience Framework aus.
Wählen Sie "Richtlinienschlüssel" aus.
Wählen Sie Hinzufügen aus.
Wählen Sie unter "Optionen" die Option "Manuell" aus.
Geben Sie einen Richtlinienschlüsselnamen für den Richtlinienschlüssel ein. Das Präfix B2C_1A_ wird an den Schlüsselnamen angefügt.
Geben Sie in Secret den Client Secret von xID ein.
Wählen Sie für die Schlüsselverwendung"Signatur" aus.
Wählen Sie "Erstellen" aus.

Hinweis

In Azure AD B2C gelten benutzerdefinierte Richtlinien für komplexe Szenarien.

Siehe Übersicht über Benutzerflüsse und benutzerdefinierte Richtlinien.

Konfigurieren von xID als Identitätsanbieter

Damit sich Benutzer mit xID anmelden können, müssen Sie xID zu einem Anspruchsanbieter machen, mit dem Azure AD B2C über einen Endpunkt kommuniziert. Der Endpunkt stellt Ansprüche bereit, die Azure AD B2C zum Überprüfen der Benutzerauthentifizierung mit einer digitalen Identität auf dem Gerät verwendet.

Hinzufügen von xID als Anspruchsanbieter

Rufen Sie die benutzerdefinierten Richtlinienstartpakete von GitHub ab, und aktualisieren Sie dann die XML-Dateien im SocialAccounts-Startpaket mit Ihrem Azure AD B2C-Mandantennamen.

Laden Sie die ZIP-Datei active-directory-b2c-policy-starterpack-main herunter, oder klonen Sie das Repository. Siehe Azure-Samples/active-directory-b2c-custom-policy-starterpack.
Ersetzen Sie in den Dateien im Verzeichnis "SocialAccounts " die Zeichenfolge yourtenant durch den Namen Ihres Azure AD B2C-Mandanten. Beispielsweise wird yourtenant.onmicrosoft.com zu contoso.onmicrosoft.com.
Öffnen Sie die SocialAccounts/TrustFrameworkExtensions.xml.
Suchen Sie das ClaimsProviders-Element . Wenn kein Element vorhanden ist, fügen Sie es unter dem Stammelement hinzu.

Fügen Sie einen neuen ClaimsProvider ähnlich dem folgenden Beispiel hinzu:


 <ClaimsProvider>
   <Domain>X-ID</Domain>
   <DisplayName>X-ID</DisplayName>
   <TechnicalProfiles>
     <TechnicalProfile Id="X-ID-OIDC">
       <DisplayName>X-ID</DisplayName>
       <Description>Login with your X-ID account</Description>
       <Protocol Name="OpenIdConnect" />
       <Metadata>
         <Item Key="METADATA">https://oidc-uat.x-id.io/.well-known/openid-configuration</Item>
         <!-- Update the Client ID below to the X-ID Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
         <Item Key="response_types">code</Item>
         <Item Key="scope">openid verification</Item>
         <Item Key="response_mode">query</Item>
         <Item Key="HttpBinding">POST</Item>
         <Item Key="UsePolicyInRedirectUri">false</Item>
         <Item Key="DiscoverMetadataByTokenIssuer">true</Item>
         <Item Key="token_endpoint_auth_method">client_secret_basic</Item>
         <Item Key="ClaimsEndpoint">https://oidc-uat.x-id.io/userinfo</Item>
         <Item Key="ValidTokenIssuerPrefixes">https://oidc-uat.x-id.io/</Item>
       </Metadata>
       <CryptographicKeys>
         <Key Id="client_secret" StorageReferenceId="B2C_1A_XIDSecAppSecret" />
       </CryptographicKeys>
       <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
         <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
         <OutputClaim ClaimTypeReferenceId="email" />
         <OutputClaim ClaimTypeReferenceId="sid" />
         <OutputClaim ClaimTypeReferenceId="userdataid" />
         <OutputClaim ClaimTypeReferenceId="XID_verified" />
         <OutputClaim ClaimTypeReferenceId="email_verified" />
         <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
         <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://oidc-uat.x-id.io/" />
         <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
       </OutputClaims>
       <OutputClaimsTransformations>
         <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
         <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
         <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
         <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
       </OutputClaimsTransformations>
       <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
     </TechnicalProfile>

   <TechnicalProfile Id="X-ID-Userdata">
     <DisplayName>Userdata (Personal Information)</DisplayName>
     <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
     <Metadata>
       <Item Key="ServiceUrl">https://api-uat.x-id.io/v4/verification/userdata</Item>
       <Item Key="SendClaimsIn">Header</Item>
       <Item Key="AuthenticationType">Bearer</Item>
       <Item Key="UseClaimAsBearerToken">identityProviderAccessToken</Item>
       <!-- <Item Key="AllowInsecureAuthInProduction">true</Item> -->
       <Item Key="DebugMode">true</Item>
       <Item Key="DefaultUserMessageIfRequestFailed">Can't process your request right now, please try again later.</Item>
     </Metadata>
     <InputClaims>
       <!-- Claims sent to your REST API -->
       <InputClaim ClaimTypeReferenceId="identityProviderAccessToken" />
     </InputClaims>
     <OutputClaims>
       <!-- Claims parsed from your REST API -->
       <OutputClaim ClaimTypeReferenceId="last_name" />
       <OutputClaim ClaimTypeReferenceId="first_name" />
       <OutputClaim ClaimTypeReferenceId="previous_name" />
       <OutputClaim ClaimTypeReferenceId="year" />
       <OutputClaim ClaimTypeReferenceId="month" />
       <OutputClaim ClaimTypeReferenceId="date" />
       <OutputClaim ClaimTypeReferenceId="prefecture" />
       <OutputClaim ClaimTypeReferenceId="city" />
       <OutputClaim ClaimTypeReferenceId="address" />
       <OutputClaim ClaimTypeReferenceId="sub_char_common_name" />
       <OutputClaim ClaimTypeReferenceId="sub_char_previous_name" />
       <OutputClaim ClaimTypeReferenceId="sub_char_address" />
       <OutputClaim ClaimTypeReferenceId="gender" />
       <OutputClaim ClaimTypeReferenceId="verified_at" />
     </OutputClaims>
     <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
   </TechnicalProfile>
 </TechnicalProfiles>
 </ClaimsProvider>

Legen Sie client_id mit Ihrer xID-Anwendungs-ID fest.
Wählen Sie Speichern aus.

Hinzufügen einer Benutzerreise

Fügen Sie einen Identitätsanbieter zu Anmeldeseiten hinzu.

Wenn Sie über einen benutzerdefinierten Benutzerablauf verfügen, gehen Sie zu Identitätsanbieter zu einem Benutzerablauf hinzufügen. Oder erstellen Sie ein Duplikat einer User Journey-Vorlage:
Öffnen Sie im Starter Pack die Datei TrustFrameworkBase.xml.
Suchen und kopieren Sie den Inhalt des UserJourneys-Elements , das enthält ID=SignUpOrSignIn.
Öffnen Sie TrustFrameworkExtensions.xml und suchen Sie das UserJourneys-Element. Wenn keins vorhanden ist, fügen Sie eins hinzu.
Fügen Sie den Inhalt des UserJourney-Elements als untergeordnetes Element des UserJourneys-Elements ein.
Benennen Sie die Benutzerreise-ID um. Beispiel: ID=CustomSignUpSignIn

Hinzufügen des Identitätsanbieters zu einer User Journey

Fügen Sie den neuen Identitätsanbieter zur Nutzerreise hinzu.

Suchen Sie in der User Journey nach dem Orchestrierungsschrittelement mit „Type=CombinedSignInAndSignUp“ oder „Type=ClaimsProviderSelection“. Es ist in der Regel der erste Orchestrierungsschritt. Das ClaimsProviderSelections-Element verfügt über eine Identitätsanbieterliste für die Anmeldung. Die Reihenfolge der Elemente steuert die Reihenfolge der Anmeldeschaltflächen.
Fügen Sie ein ClaimsProviderSelection-XML-Element hinzu.
Legen Sie den Wert von TargetClaimsExchangeId auf einen freundlichen Namen fest.
Fügen Sie ein ClaimsExchange-Element hinzu.
Legen Sie die ID auf den Wert der Zielanspruchsaustausch-ID fest. Diese Änderung verknüpft die xID-Schaltfläche mit X-IDExchange Aktion.
Aktualisieren Sie den TechnicalProfileReferenceId-Wert auf die von Ihnen erstellte technische Profil-ID (X-ID-OIDC).
Fügen Sie einen Orchestrierungsschritt hinzu, um den xID UserInfo-Endpunkt aufzurufen, um Ansprüche über den authentifizierten Benutzer X-ID-Userdatazurückzugeben.

Die folgende XML veranschaulicht die Benutzerreise-Orchestrierung mit dem xID-Identitätsanbieter.


 <UserJourney Id="CombinedSignInAndSignUp">
   <OrchestrationSteps>

     <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
       <ClaimsProviderSelections>
         <ClaimsProviderSelection TargetClaimsExchangeId="X-IDExchange" />
       </ClaimsProviderSelections>
     </OrchestrationStep>

     <OrchestrationStep Order="2" Type="ClaimsExchange">
       <ClaimsExchanges>
         <ClaimsExchange Id="X-IDExchange" TechnicalProfileReferenceId="X-ID-OIDC" />
       </ClaimsExchanges>
     </OrchestrationStep>

     <OrchestrationStep Order="3" Type="ClaimsExchange">
       <ClaimsExchanges>
         <ClaimsExchange Id="X-ID-Userdata" TechnicalProfileReferenceId="X-ID-Userdata" />
       </ClaimsExchanges>
     </OrchestrationStep>

     <!-- For social IDP authentication, attempt to find the user account in the directory. -->
     <OrchestrationStep Order="4" Type="ClaimsExchange">
       <ClaimsExchanges>
         <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
       </ClaimsExchanges>
     </OrchestrationStep>

     <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId).  -->
     <OrchestrationStep Order="5" Type="ClaimsExchange">
       <Preconditions>
         <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
           <Value>objectId</Value>
           <Action>SkipThisOrchestrationStep</Action>
         </Precondition>
       </Preconditions>
       <ClaimsExchanges>
         <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
       </ClaimsExchanges>
     </OrchestrationStep>

     <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect 
          from the user. So, in that case, create the user in the directory if one does not already exist 
          (verified using objectId which would be set from the last step if account was created in the directory. -->
     <OrchestrationStep Order="6" Type="ClaimsExchange">
       <Preconditions>
         <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
           <Value>objectId</Value>
           <Action>SkipThisOrchestrationStep</Action>
         </Precondition>
       </Preconditions>
       <ClaimsExchanges>
         <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
       </ClaimsExchanges>
     </OrchestrationStep>

     <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

   </OrchestrationSteps>
   <ClientDefinition ReferenceId="DefaultWeb" />
 </UserJourney>

Es gibt Identitätsansprüche, die xID unterstützt und die im Rahmen der Richtlinie referenziert werden. Das Anspruchsschema gibt an, wo Sie die Ansprüche deklarieren. Das ClaimsSchema-Element weist eine ClaimType-Elementliste auf. Das ClaimType-Element enthält das ID-Attribut, bei dem es sich um den Anspruchsnamen handelt.

Öffnen Sie die Datei TrustFrameworksExtension.xml.
Suchen Sie das BuildingBlocks-Element .
Fügen Sie das folgende ClaimType-Element im ClaimsSchema-Element der TrustFrameworksExtension.xml-Richtlinie hinzu.

 <BuildingBlocks>
    <ClaimsSchema>
      <!-- xID -->
      <ClaimType Id="sid">
        <DisplayName>sid</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="userdataid">
        <DisplayName>userdataid</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="xid_verified">
        <DisplayName>xid_verified</DisplayName>
        <DataType>boolean</DataType>
      </ClaimType>
      <ClaimType Id="email_verified">
        <DisplayName>email_verified</DisplayName>
        <DataType>boolean</DataType>
      </ClaimType>
      <ClaimType Id="identityProviderAccessToken">
        <DisplayName>Identity Provider Access Token</DisplayName>
        <DataType>string</DataType>
        <AdminHelpText>Stores the access token of the identity provider.</AdminHelpText>
      </ClaimType>
      <ClaimType Id="last_name">
        <DisplayName>last_name</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="first_name">
        <DisplayName>first_name</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="previous_name">
        <DisplayName>previous_name</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="year">
        <DisplayName>year</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="month">
        <DisplayName>month</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="date">
        <DisplayName>date</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="prefecture">
        <DisplayName>prefecture</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="city">
        <DisplayName>city</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="address">
        <DisplayName>address</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="sub_char_common_name">
        <DisplayName>sub_char_common_name</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="sub_char_previous_name">
        <DisplayName>sub_char_previous_name</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="sub_char_address">
        <DisplayName>sub_char_address</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <ClaimType Id="verified_at">
        <DisplayName>verified_at</DisplayName>
        <DataType>int</DataType>
      </ClaimType>
      <ClaimType Id="gender">
        <DisplayName>Gender</DisplayName>
        <DataType>string</DataType>
        <DefaultPartnerClaimTypes>
          <Protocol Name="OpenIdConnect" PartnerClaimType="gender" />
        </DefaultPartnerClaimTypes>
        <AdminHelpText>The user's gender.</AdminHelpText>
        <UserHelpText>Your gender.</UserHelpText>
        <UserInputType>TextBox</UserInputType>
      </ClaimType>
      <ClaimType Id="correlationId">
        <DisplayName>correlation ID</DisplayName>
        <DataType>string</DataType>
      </ClaimType>
      <!-- xID -->
    </ClaimsSchema>
  </BuildingBlocks>

Konfigurieren einer Richtlinie für die vertrauende Seite

Die Richtlinie der vertrauenden Partei, z. B. SignUpSignIn.xml, gibt den Benutzerpfad an, den Azure AD B2C ausführt.

Suchen Sie in der vertrauenden Seite das DefaultUserJourney-Element.
Aktualisieren Sie die ReferenceId so, dass sie mit der Benutzerreise-ID übereinstimmt, die Sie dem Identitätsanbieter hinzugefügt haben.

Im folgenden Beispiel wird für den xID-Benutzerweg die ReferenceId auf CombinedSignInAndSignUp gesetzt.

   <RelyingParty>
        <DefaultUserJourney ReferenceId="CombinedSignInAndSignUp" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
          <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub" />
          <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
          <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          <OutputClaim ClaimTypeReferenceId="issuerUserId" />
          <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="first_name" />
          <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="last_name" />
          <OutputClaim ClaimTypeReferenceId="previous_name" />
          <OutputClaim ClaimTypeReferenceId="year" />
          <OutputClaim ClaimTypeReferenceId="month" />
          <OutputClaim ClaimTypeReferenceId="date" />
          <OutputClaim ClaimTypeReferenceId="prefecture" />
          <OutputClaim ClaimTypeReferenceId="city" />
          <OutputClaim ClaimTypeReferenceId="address" />
          <OutputClaim ClaimTypeReferenceId="sub_char_common_name" />
          <OutputClaim ClaimTypeReferenceId="sub_char_previous_name" />
          <OutputClaim ClaimTypeReferenceId="sub_char_address" />
          <OutputClaim ClaimTypeReferenceId="gender" />
          <OutputClaim ClaimTypeReferenceId="verified_at" />
          <OutputClaim ClaimTypeReferenceId="email" />
          <OutputClaim ClaimTypeReferenceId="sid" />
          <OutputClaim ClaimTypeReferenceId="userdataid" />
          <OutputClaim ClaimTypeReferenceId="xid_verified" />
          <OutputClaim ClaimTypeReferenceId="email_verified" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

Hochladen der benutzerdefinierten Richtlinie

Verwenden Sie für die folgenden Anweisungen das Verzeichnis mit dem Azure AD B2C-Mandanten.

Melden Sie sich beim Azure-Portal an.
Wählen Sie auf der Portalsymbolleiste die Verzeichnisse + Abonnements aus.
Auf der Seite Portal-Einstellungen | Verzeichnisse + Abonnements in der Liste Verzeichnisnamen. Suchen Sie Ihr Azure AD B2C-Verzeichnis.
Wählen Sie Wechseln aus.
Suchen Sie im Azure-Portal nach Azure AD B2C, und wählen Sie sie aus.
Wählen Sie unter "Richtlinien " die Option "Identity Experience Framework" aus.
Wählen Sie "Benutzerdefinierte Richtlinie hochladen" aus.
Laden Sie die Dateien in der folgenden Reihenfolge hoch:

Basisrichtliniendatei: TrustFrameworkBase.xml
Erweiterungsrichtlinie: TrustFrameworkExtensions.xml
Richtlinie für die vertrauende Seite: SignUpSignIn.xml

Testen der benutzerdefinierten Richtlinie

Wählen Sie in Ihrem Azure AD B2C-Mandanten unter "Richtlinien" die Option "Identity Experience Framework" aus.
Wählen Sie unter "Benutzerdefinierte Richtlinien" "CustomSignUpSignIn" aus.
Wählen Sie für "Anwendung" die Webanwendung aus, die Sie registriert haben. Die Antwort-URL lautet https://jwt.ms.
Wählen Sie Jetzt ausführen aus.
Der Browser leitet zur xID-Anmeldeseite um.
Der Browser wird zu https://jwt.ms umgeleitet. Der von Azure AD B2C zurückgegebene Tokeninhalt wird angezeigt.