Konfigurieren von xID mit Azure Active Directory B2C für die kennwortlose Authentifizierung
In diesem Tutorial erfahren Sie, wie Sie die Azure AD B2C-Authentifizierung (Azure AD B2C) in die xID-Lösung für digitale IDs integrieren. Die xID-App bietet Benutzern eine kennwortlose, sichere Multi-Faktor-Authentifizierung. Die My Number Card, die digitale ID-Karte, die von der japanischen Regierung ausgestellt wurde, überprüft xID-authentifizierte Benutzeridentitäten. Organisationen können über die xID-API überprüfte personenbezogene Informationen (Kundeninhalte) für Ihre Benutzer abrufen. Darüber hinaus generiert die xID-App einen privaten Schlüssel in einem sicheren Bereich auf mobilen Geräten der Benutzer, sodass diese zu Geräte für die digitale Signatur werden.
Voraussetzungen
Ein Azure-Abonnement
- Wenn Sie über kein Abonnement verfügen, können Sie ein kostenloses Azure-Konto anfordern.
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.
Informationen zum xID-Client erhalten Sie auf der xid.inc-Seite Kontakt von:
- Client-ID
- Geheimer Clientschlüssel
- Umleitungs-URL
- Bereiche
Wechseln Sie zu x-id.me, um die xID-App auf einem mobilen Gerät zu installieren:
- My Number Card
- Wenn Sie die API-UAT-Version verwenden, rufen Sie die UAT-Version der xID-App ab. Siehe Kontakt.
Beschreibung des Szenarios
Das folgende Diagramm veranschaulicht diese Architektur.
- Auf der Azure AD B2C-Anmeldeseite meldet sich der Benutzer an oder registriert sich.
- Azure AD B2C leitet Benutzer mithilfe einer OIDC-Anforderung (OpenID Connect) zum Endpunkt der xID-Autorisierungs-API um. Ein OIDC-Endpunkt verfügt über Endpunktinformationen. Der xID-Identitätsanbieter (IdP) leitet den Benutzer zur Anmeldeseite der xID-Autorisierung um. Der Benutzer gibt die E-Mail-Adresse ein.
- Der xID-IdP sendet eine Pushbenachrichtigung an das mobile Benutzergerät.
- 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 den xID-IdP.
- Ein Einwilligungsbildschirm wird angezeigt, um dem Dienst personenbezogene Informationen zu geben.
- Der xID-IdP gibt den OAuth-Autorisierungscode an Azure AD B2C zurück.
- Azure AD B2C sendet eine Tokenanforderung mit dem Autorisierungscode.
- Der xID-IdP überprüft die Tokenanforderung. Falls gültig, wird das OAuth-Zugriffstoken und das ID-Token mit Benutzerbezeichner und E-Mail-Adresse zurückgegeben.
- Wenn Kundeninhalte von Benutzern benötigt werden, ruft Azure AD B2C die xID-Benutzerdaten-API auf.
- Die xID-Benutzerdaten-API gibt die verschlüsselten Kundeninhalte zurück. Benutzer entschlüsseln diese mit einem privaten Schlüssel, der erstellt wird, wenn xID-Clientinformationen angefordert werden.
- Benutzern wird der Zugriff auf die Kundenanwendung gewährt oder verweigert.
Installieren von xID
- Um API-Dokumente anzufordern, füllen Sie das Anforderungsformular aus. Wechseln Sie zu Kontakt.
- Geben Sie in der Nachricht an, dass Sie Azure AD B2C verwenden.
- Ein xID-Vertriebsmitarbeiter kontaktiert Sie.
- Befolgen Sie die Anweisungen in der xID-API-Dokumentation.
- Fordern Sie einen xID-API-Client an.
- Das xID-Technologieteam sendet Ihnen die Clientinformationen in 3 bis 4 Arbeitstagen zu.
- Geben Sie einen Umleitungs-URI auf Ihrer Website mit dem folgenden Muster 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, dann können sie mit Azure AD B2C interagieren.
Weitere Informationen: In Active Directory B2C verwendbare Anwendungstypen
Zum Testen registrieren Sie https://jwt.ms, eine Microsoft-Webanwendung mit decodierten Tokeninhalten, die Ihren Browser nicht verlassen.
Registrieren Sie eine Webanwendung, und aktivieren Sie die implizite Genehmigung von ID-Token.
Schließen Sie Tutorial: Registrieren einer Webanwendung in Azure AD B2C ab.
Erstellen eines xID-Richtlinienschlüssels
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 Toolbar des Portals Verzeichnisse + Abonnements aus.
- Suchen Sie auf der Seite Portaleinstellungen | Verzeichnisse + Abonnements Ihr Azure AD B2C-Verzeichnis in der Liste „Verzeichnisname“.
- Wählen Sie Wechseln aus.
- Wählen Sie in der linken oberen Ecke im Azure-Portal die Option Alle Dienste aus.
- Suchen Sie nach Azure AD B2C, und wählen Sie diese Option aus.
- Wählen Sie unter Übersicht die Option Identity Experience Framework aus.
- Wählen Sie Richtlinienschlüssel aus.
- Wählen Sie Hinzufügen.
- Wählen Sie unter Optionen den Eintrag Manuell aus.
- Geben Sie der Richtlinie für den Richtlinienschlüssel einen Namen. Das Präfix „
B2C_1A_“ wird dem Schlüsselnamen angefügt. - Geben Sie unter Geheimnis den geheimen Clientschlüssel von xID ein.
- Wählen Sie unter SchlüsselverwendungSignatur aus.
- Klicken Sie auf Erstellen.
Hinweis
In Azure AD B2C sind benutzerdefinierte Richtlinien für komplexe Szenarien gedacht.
Lesen Sie dazu Übersicht über Benutzerflows und benutzerdefinierte Richtlinien.
Konfigurieren von xID als Identitätsanbieter
Damit sich Benutzer über xID anmelden können, definieren Sie xID als Anspruchsanbieter, 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
Holen Sie sich die Starter Packs für benutzerdefinierte Richtlinien-von GitHub, und aktualisieren Sie dann die XML-Dateien im Starter Pack „SocialAccounts“ mit dem Namen Ihres Azure AD B2C-Mandanten.
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
yourtenantdurch den Namen Ihres Azure AD B2C-Mandanten.yourtenant.onmicrosoft.comwird beispielsweise zucontoso.onmicrosoft.com.Öffnen Sie die Datei SocialAccounts/TrustFrameworkExtensions.xml.
Suchen Sie nach dem Element ClaimsProviders. Wenn keine vorhanden ist, fügen Sie sie unter dem Stammelement hinzu.
Fügen Sie ein neues ClaimsProvider-Element wie im 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">00000000-0000-0000-0000-000000000000</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 User Journey
Fügen Sie zu den Anmeldeseiten einen Identitätsanbieter hinzu.
- Wenn Sie über eine benutzerdefinierte User Journey verfügen, wechseln Sie zu Hinzufügen des Identitätsanbieters zu einer User Journey. Oder erstellen Sie ein Duplikat einer User Journey-Vorlage:
- Öffnen Sie im Starter-Paket die Datei TrustFrameworkBase.xml.
- Suchen und kopieren Sie den Inhalt des Elements UserJourneys, das
ID=SignUpOrSignInenthält. - Öffnen Sie die Datei TrustFrameworkExtensions.xml, und suchen Sie nach dem UserJourneys-Element. Wenn keines vorhanden ist, fügen Sie eines hinzu.
- Fügen Sie den Inhalt des UserJourney-Elements als untergeordnetes Element des „UserJourneys“-Elements ein.
- Benennen Sie die User Journey-ID um. Zum Beispiel,
ID=CustomSignUpSignIn
Hinzufügen des Identitätsanbieters zu einer User Journey
Fügen Sie der User Journey den neuen Identitätsanbieter hinzu.
- Suchen Sie in der User Journey nach dem Orchestrierungsschrittelement mit Type=
CombinedSignInAndSignUpoder Type=ClaimsProviderSelection. Dies ist in der Regel der erste Orchestrierungsschritt. Das Element ClaimsProviderSelections enthält eine Identitätsanbieterliste für die Anmeldung. Die Reihenfolge der Elemente bestimmt die Reihenfolge der Anmeldeschaltflächen. - Fügen Sie ein ClaimsProviderSelection-XML-Element hinzu.
- Legen Sie für TargetClaimsExchangeId einen Anzeigenamen fest.
- Fügen Sie ein ClaimsExchange-Element hinzu.
- Legen Sie die ID auf den Wert der Zielanspruchsaustausch-ID fest. Durch diese Änderung wird die xID-Schaltfläche mit einer
X-IDExchange-Aktion verknüpft. - Aktualisieren Sie den Wert TechnicalProfileReferenceId auf die von Ihnen erstellte ID des technischen Profils (
X-ID-OIDC). - Fügen Sie einen Orchestrierungsschritt hinzu, um den xID UserInfo-Endpunkt aufzurufen, um Ansprüche über den authentifizierten Benutzer zurückzugeben (
X-ID-Userdata).
Der folgende XML-Code veranschaulicht die User Journey-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 im Rahmen der Richtlinie referenziert werden. Im Anspruchsschema deklarieren Sie die Ansprüche. Das ClaimsSchema-Element verfügt über eine ClaimType-Elementliste. Das ClaimType-Element enthält das ID-Attribut, bei dem es sich um den Anspruchsnamen handelt.
- Öffnen Sie die Datei TrustFrameworksExtension.xml.
- Suchen Sie nach dem Element BuildingBlocks.
- 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 für die vertrauende Seite, z. B. SignUpSignIn.xml, gibt die von Azure AD B2C ausgeführte User Journey an.
- Suchen Sie in der vertrauenden Seite das DefaultUserJourney-Element.
- Aktualisieren Sie ReferenceId auf die ID der User Journey, die Sie zum Identitätsanbieter hinzugefügt haben.
Im folgenden Beispiel wird ReferenceId für die xID-User Journey auf CombinedSignInAndSignUp festgelegt.
<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 Symbolleiste des Portals die Option Verzeichnisse und Abonnements aus.
- Auf der Seite Portaleinstellungen | Verzeichnisse + Abonnements in der Liste Verzeichnisname. Suchen Sie Ihr Azure AD B2C-Verzeichnis.
- Wählen Sie Wechseln aus.
- Suchen Sie im Azure-Portal nach Azure AD B2C, und klicken Sie darauf.
- Klicken Sie unter „Richtlinien“ auf Identity Experience Framework.
- 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 die Richtlinie CustomSignUpSignIn aus.
- Wählen Sie als Anwendung die Webanwendung aus, die Sie registriert haben. Die Antwort-URL lautet
https://jwt.ms. - Wählen Sie Jetzt ausführen aus.
- Der Browser wird zur xID-Anmeldeseite umgeleitet.
- Der Browser wird zu
https://jwt.msumgeleitet. Die von Azure AD B2C zurückgegebenen Tokeninhalte werden angezeigt.