Konfigurieren der Trusona Authentication Cloud mit Azure Active Directory B2C

2025-05-08

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 Beispiellernprogramm erfahren Sie, wie Sie die Azure AD B2C-Authentifizierung in die Trusona Authentication Cloud integrieren. Es ist ein cloudbasierter Dienst, mit dem Benutzer sich mit einer Tap-and-Go-Erfahrung authentifizieren können, ohne dass eine mobile Authentifikator-App erforderlich ist.

Zu den Vorteilen der Integration der Trusona Authentication Cloud mit Azure AD B2C gehören:

Bereitstellen einer starken Authentifizierung mit einer besseren Benutzererfahrung
- Glücklichere Benutzer, die mehr online verbringen
- Geringere Fluktuation und weniger Abgänge, höhere Umsätze
- Höhere Kundenbindung, Lebenszeitwert (LTV)
Niedrigere Kosten für den Betrieb des Unternehmens
- Reduzierung von Kontoübernahmen und Kontoteilung
- Verringerter Betrug und weniger manuelle Betrugsanalysemaßnahmen
- Reduzierte Ausgaben durch Outsourcing manueller Überprüfungen
Entfernen von Kennwörtern
- Keine Kennwortzurücksetzungen mehr
- Reduzierte Anrufcenterbeschwerden
- Schnelle, einfache, reibungslose Anmeldungen mithilfe von Passkeys

Voraussetzungen

Um zu beginnen, benötigen Sie Folgendes:

Ein Trusona Authentication Cloud-Testkonto. Wenden Sie sich an Trusona, um ein Konto anzufordern.
Ein Azure-Abonnement. Wenn Sie kein Abonnement haben, können Sie ein kostenloses Konto erhalten.
Ein Azure AD B2C-Mandant , der mit Ihrem Azure-Abonnement verknüpft ist.

Führen Sie die Schritte im Artikel erste Schritte mit benutzerdefinierten Richtlinien in Azure AD B2C aus.

Szenariobeschreibung

WebAuthentifizierungsstandard – WebAuthn implementiert moderne Betriebssysteme und Browser zur Unterstützung der Authentifizierung über Fingerdruck, Windows Hello oder externe FIDO-Geräte wie USB, Bluetooth und One Time Password (OTP).

In diesem Szenario fungiert Trusona als Identitätsanbieter (IdP) für Azure AD B2C, um die kennwortlose Authentifizierung zu aktivieren. Die folgenden Komponenten bilden die Lösung:

Eine kombinierte Azure AD B2C-Anmelde- und Registrierungsrichtlinie.
Trusona Authentication Cloud zu Azure AD B2C als IdP hinzugefügt.

Screenshot des Trusona-Architekturdiagramms.

Schritte	BESCHREIBUNG
1.	Ein Benutzer versucht, sich über seinen Browser bei der Webanwendung anzumelden.
2.	Die Webanwendung leitet zur Azure AD B2C-Registrierungs- und Anmelderichtlinie um.
3.	Azure AD B2C leitet den Benutzer zur Authentifizierung an den Trusona Authentication Cloud OpenID Connect (OIDC)-IdP weiter.
4.	Dem Benutzer wird eine Anmeldewebseite angezeigt, die nach ihrem Benutzernamen fragt – in der Regel eine E-Mail-Adresse.
5.	Der Benutzer gibt seine E-Mail-Adresse ein und wählt die Schaltfläche " Weiter " aus. Wenn das Konto des Benutzers in der Trusona Authentication Cloud nicht gefunden wird, wird eine Antwort an den Browser gesendet, der einen WebAuthn-Registrierungsprozess auf dem Gerät initiiert. Andernfalls wird eine Antwort an den Browser gesendet, der einen WebAuthn-Authentifizierungsprozess startet.
6	Der Benutzer wird aufgefordert, die zu verwendenden Anmeldeinformationen auszuwählen. Der Schlüssel ist der Domäne der Webanwendung oder einem Hardwaresicherheitsschlüssel zugeordnet. Sobald der Benutzer eine Anmeldeinformationen auswählt, fordert das Betriebssystem den Benutzer auf, eine biometrische, Kennung oder PIN zu verwenden, um seine Identität zu bestätigen. Dadurch wird die sichere Enklave/vertrauenswürdige Ausführungsumgebung entsperrt, die eine Authentifizierungsbehauptung generiert, die vom privaten Schlüssel signiert ist, der den ausgewählten Anmeldedaten zugeordnet ist.
7.	Die Authentifizierungs assertion wird zur Überprüfung an den Trusona-Clouddienst zurückgegeben.
8.	Nach der Überprüfung erstellt Trusona Authentication Cloud (IdP) ein OIDC-ID-Token und leitet es dann an Azure AD B2C (Dienstanbieter) weiter. Azure AD B2C überprüft die Signatur des Tokens und des Ausstellers anhand der Werte im OpenID-Ermittlungsdokument von Trusona. Diese Details wurden während des IdP-Setups konfiguriert. Nach der Überprüfung stellt Azure AD B2C ein OIDC-ID-Token aus (je nach Umfang) und leitet den Benutzer mit dem Token zurück zur initiierenden Anwendung.
9.	Die Webanwendung (oder die Entwicklerbibliotheken, die zur Implementierung der Authentifizierung verwendet werden), ruft das Token ab und überprüft die Authentizität des Azure AD B2C-Tokens. Wenn dies der Fall ist,extrahiert sie die Ansprüche und übergibt sie an die Webanwendung, die sie verwenden soll.
10.	Nach der Überprüfung wird dem Benutzer der Zugriff gewährt/verweigert.

Schritt 1: Onboarding mit Trusona Authentication Cloud

Melden Sie sich beim Trusona-Portal an.
Wählen Sie im linken Navigationsbereich "Einstellungen" aus.
Wählen Sie im Menü "Einstellungen" den Schieberegler zum Aktivieren von OIDC aus.
Wählen Sie die entsprechenden Eingaben aus, und geben Sie die Umleitungs-URLhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp an.
Generieren Sie einen geheimen Schlüssel, und kopieren Sie den Schlüssel für die Verwendung in Ihrem Azure AD B2C-Setup.
Hinweis
1. Das Trusona-Portal unterstützt die Self-Service-Registrierung. Bei der Registrierung werden Sie einem Trusona-Konto mit schreibgeschützten Rechten zugewiesen. Anschließend weist Trusona Ihnen das richtige Konto zu und erhöht Ihre Rechte auf Lese-/Schreibzugriff basierend auf der Zugriffssteuerungsrichtlinie Ihrer Organisation für Portalbenutzer.
2. Der ursprüngliche Domänenname der Microsoft Entra-ID wird als Clientumleitungshost verwendet.

Schritt 2: Registrieren einer Webanwendung in Azure AD B2C

Bevor Ihre Anwendungen mit Azure AD B2C interagieren können, müssen sie in Ihrem Kundenmandanten registriert sein. In diesem Lernprogramm erfahren Sie, wie Sie eine Webanwendung mithilfe des Azure-Portals registrieren. Für Testzwecke wie in diesem Tutorial registrieren Sie https://jwt.ms, eine von Microsoft betriebene Webanwendung, die den entschlüsselten Inhalt eines Tokens anzeigt (der Inhalt des Tokens verlässt niemals Ihren Browser). Um eine Webanwendung in Ihrem Azure AD B2C-Mandanten zu registrieren, verwenden Sie unsere neue einheitliche App-Registrierung.

Melden Sie sich beim Azure-Portal an.
Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.
Suchen Sie im Azure-Portal nach Azure AD B2C, und wählen Sie diese Option dann aus.
Wählen Sie App-Registrierungen aus, und wählen Sie dann Registrierung einer neuen Anwendung aus.
Geben Sie einen Namen für die Anwendung ein. Beispiel: jwt ms.
Wählen Sie unter Unterstützte Kontotypen die Option Konten in einem beliebigen Identitätsanbieter oder Organisationsverzeichnis (zum Authentifizieren von Benutzenden mit Benutzerflows) aus.
Wählen Sie unter Umleitungs-URI die Option Web aus, und geben Sie https://jwt.ms in das Textfeld "URL" ein.

Der Umleitungs-URI ist der Endpunkt, an den der Autorisierungsserver Azure AD B2C in diesem Fall den Benutzer sendet. Nach Abschluss der Interaktion mit dem Benutzer wird nach erfolgreicher Autorisierung ein Zugriffstoken oder Autorisierungscode gesendet. In einer Produktionsanwendung handelt es sich in der Regel um einen öffentlich zugänglichen Endpunkt, an dem Ihre App ausgeführt wird, etwa um https://contoso.com/auth-response. Für Testzwecke wie dieses Tutorial können Sie es auf https://jwt.ms festlegen, eine Microsoft-eigene Webanwendung, die den decodierten Inhalt eines Tokens anzeigt (der Inhalt des Tokens verlässt nie Ihren Browser). Während der App-Entwicklung können Sie den Endpunkt hinzufügen, an dem die Anwendung lokal lauscht, etwa https://localhost:5000. Sie können Umleitungs-URIs in Ihren registrierten Anwendungen jederzeit hinzufügen und ändern.

Die folgenden Einschränkungen gelten für die Umleitung von Uniform Resource Identifiers (URI):
- Die Antwort-URL muss mit dem Schema https beginnen, sofern Sie keine localhost-Umleitungs-URL verwenden.
- Bei der Antwort-URL muss die Groß-/Kleinschreibung beachtet werden. Die Groß-/Kleinschreibung muss der Groß-/Kleinschreibung des URL-Pfads Ihrer ausgeführten Anwendung entsprechen. Wenn Ihre Anwendung beispielsweise .../abc/response-oidc als Teil des Pfads enthält, geben Sie in der Antwort-URL nicht .../ABC/response-oidc an. Weil der Webbrowser bei Pfaden die Groß-/Kleinschreibung beachtet, werden Cookies, die .../abc/response-oidc zugeordnet sind, möglicherweise ausgeschlossen, wenn eine Umleitung an die anders geschriebene (nicht übereinstimmende) URL .../ABC/response-oidc erfolgt.
- Die Antwort-URL sollte den nachgestellten Schrägstrich einschließen oder ausschließen, je nachdem, wie Ihre Anwendung dies erwartet. Zum Beispiel können https://contoso.com/auth-response und https://contoso.com/auth-response/ als nicht übereinstimmende URLs in Ihrer Anwendung behandelt werden.
Aktivieren Sie unter Berechtigungen das Kontrollkästchen Administratoreinwilligung für openid- und offline_access-Berechtigungen erteilen.
Wählen Sie Registrieren aus.

Implizite Gewährung von ID-Token aktivieren

Sie können den impliziten Genehmigungsfluss aktivieren, um diese App-Registrierung zum Testen eines Benutzerablaufs zu Testzwecken zu verwenden.

Wählen Sie die App-Registrierung aus, die Sie erstellt haben.
Wählen Sie unter Verwalten die Option Authentifizierung aus.
Aktivieren Sie unter Implizite Genehmigung und Hybridflows die Kontrollkästchen Zugriffstoken (werden für implizite Flows verwendet) und ID-Token (für implizite und Hybridflows verwendet).
Wählen Sie Speichern aus.

Hinweis

Wenn Sie die implizite Erteilung aktivieren, um einen Benutzerablauf zu testen, stellen Sie sicher, dass Sie die Einstellungen für den impliziten Genehmigungsfluss deaktivieren, bevor Sie Ihre App in der Produktion bereitstellen.

Schritt 3: Konfigurieren der Trusona Authentication Cloud als IdP in Azure AD B2C

Melden Sie sich beim Azure-Portal als Administrator für die Rollen "Externer Identitätsanbieter" und "B2C-Benutzerflussadministrator" in Ihrem Azure AD B2C-Mandanten an.
Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.
Wählen Sie "Alle Dienste " in der oberen linken Ecke des Azure-Portals aus, suchen Und wählen Sie Azure AD B2C aus.
Navigieren Sie zu Dashboard>Azure Active Directory B2C>Identitätsanbieter.
Auswählen Identitätsanbieter.
Wählen Sie Hinzufügen aus.

Konfigurieren eines IdP

Wählen Sie den Identitätsanbietertyp>OpenID Connect (Vorschau) aus.

Füllen Sie das Formular aus, um den IdP einzurichten:

Eigentum	Wert
Metadaten-URL	`https://authcloud.trusona.net/.well-known/openid-configuration`
Kunden-ID	im Trusona Authentication Cloud-Portal verfügbar
Geheimer Clientschlüssel	im Trusona Authentication Cloud-Portal verfügbar
Umfang	OpenID-Profil-E-Mail
Antworttyp	Code
Antwortmodus	form_post

Wählen Sie OK aus.
Wählen Sie Ansprüche dieses Identitätsanbieters zuordnen aus.
Füllen Sie das Formular aus, um den Identitätsanbieter zuzuordnen:

Eigentum Wert

UserID sub

Anzeigename Spitzname

Vorname given_name

Familienname Familienname

Antwortmodus E-Mail
Wählen Sie "OK" aus, um das Setup für Ihren neuen OIDC IdP abzuschließen.

Eigentum	Wert
UserID	sub
Anzeigename	Spitzname
Vorname	given_name
Familienname	Familienname
Antwortmodus	E-Mail

Schritt 4: Erstellen einer Benutzerflussrichtlinie

Sie sollten Trusona jetzt als neuen OpenID Connect Identity Provider in Ihren B2C IdPs aufgeführt sehen.

Wählen Sie in Ihrem Azure AD B2C-Mandanten unter "Richtlinien" die Option "Benutzerflüsse" aus.
Wählen Sie "Neuer Benutzerablauf" aus.
Wählen Sie "Registrieren" und "Anmelden" aus, wählen Sie eine Version und dann " Erstellen" aus.
Geben Sie einen Namen für Ihre Richtlinie ein.
Wählen Sie im Abschnitt Identitätsanbieter Ihren neu erstellten Trusona Authentication Cloud-Identity Provider aus.

Hinweis

Da Trusona inhärent multifaktorisch ist, empfiehlt es sich, die mehrstufige Authentifizierung deaktiviert zu lassen.
Wählen Sie "Erstellen" aus.
Wählen Sie unter "Benutzerattribute und Ansprüche" die Option "Mehr anzeigen" aus. Wählen Sie im Formular mindestens ein Attribut aus, das Sie während der Einrichtung Ihres Identitätsanbieters im vorherigen Abschnitt angegeben haben.
Wählen Sie OK aus.

Schritt 5: Testen des Benutzerablaufs

Wählen Sie die von Ihnen erstellte Richtlinie aus.
Wählen Sie "Benutzerablauf ausführen" und dann die Einstellungen aus:

a) Anwendung: Wählen Sie die registrierte App aus, z. B. jwt ms.

b. Antwort-URL: Wählen Sie die Umleitungs-URL aus, https://jwt.msz. B. .
Wählen Sie Benutzerflow ausführen aus. Sie sollten an die Trusona Authentication Cloud umgeleitet werden. Dem Benutzer wird eine Anmeldewebseite angezeigt, die nach ihrem Benutzernamen fragt – in der Regel eine E-Mail-Adresse. Wenn das Konto des Benutzers in der Trusona Authentication Cloud nicht gefunden wird, wird eine Antwort an den Browser gesendet, der einen WebAuthn-Registrierungsprozess auf dem Gerät initiiert. Andernfalls wird eine Antwort an den Browser gesendet, der einen WebAuthn-Authentifizierungsprozess startet. Der Benutzer wird aufgefordert, die zu verwendenden Anmeldeinformationen auszuwählen. Der Schlüssel ist der Domäne der Webanwendung oder einem Hardwaresicherheitsschlüssel zugeordnet. Sobald der Benutzer eine Anmeldeinformationen auswählt, fordert das Betriebssystem den Benutzer auf, eine biometrische, Kennung oder PIN zu verwenden, um seine Identität zu bestätigen. Dadurch wird die sichere Enklave/vertrauenswürdige Ausführungsumgebung entsperrt, die eine Authentifizierungsbehauptung generiert, die vom privaten Schlüssel signiert ist, der den ausgewählten Anmeldedaten zugeordnet ist. Azure AD B2C überprüft die Trusona-Authentifizierungsantwort und gibt ein OIDC-Token aus. Er leitet den Benutzer an die initiierende Anwendung zurück, z. B. https://jwt.ms, wodurch der Inhalt des von Azure AD B2C zurückgegebenen Tokens angezeigt wird.

Schritt 3: Erstellen eines Trusona Authentication Cloud-Richtlinienschlüssels

Speichern Sie den geheimen Clientschlüssel, den Sie zuvor in Schritt 1 in Ihrem Azure AD B2C-Mandanten generiert haben.

Melden Sie sich beim Azure-Portal an.
Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.
Wählen Sie "Alle Dienste " in der oberen linken Ecke des Azure-Portals aus, und suchen Sie dann nach Azure AD B2C, und wählen Sie sie aus.
Wählen Sie auf der Seite "Übersicht" die Option "Identity Experience Framework" aus.
Wählen Sie "Richtlinienschlüssel" und dann "Hinzufügen" aus.
Wählen Sie unter "Optionen" die Option "Manuell" aus.
Geben Sie einen Namen für den Richtlinienschlüssel ein. Beispiel: TrusonaTacClientSecret. Das Präfix B2C_1A_ wird automatisch dem Namen Des Schlüssels hinzugefügt.
Geben Sie im geheimen Schlüssel Ihren geheimen Clientschlüssel ein, den Sie zuvor aufgezeichnet haben.
Wählen Sie für die Schlüsselverwendung die Option Signatureaus.
Wählen Sie "Erstellen" aus.

Schritt 4: Konfigurieren der Trusona Authentication Cloud als IdP

Tipp

Sie sollten die Azure AD B2C-Richtlinie zu diesem Zeitpunkt konfiguriert haben. Wenn nicht, befolgen Sie die Anweisungen zum Einrichten Ihres Azure AD B2C-Mandanten und zum Konfigurieren von Richtlinien.

Um Benutzern die Anmeldung mithilfe der Trusona Authentication Cloud zu ermöglichen, müssen Sie Trusona als Anspruchsanbieter definieren, mit dem Azure AD B2C über einen Endpunkt kommunizieren kann. Der Endpunkt stellt eine Reihe von Ansprüchen bereit, die von Azure AD B2C verwendet werden, um zu überprüfen, ob ein bestimmter Benutzer sich mithilfe eines Passkeys oder eines Hardwaresicherheitsschlüssels authentifiziert hat, der auf seinem Gerät verfügbar ist und die Identität des Benutzers nachweist.

Führen Sie die folgenden Schritte aus, um Trusona als Anspruchsanbieter hinzuzufügen:

Rufen Sie die benutzerdefinierten Richtlinienstartpakete von GitHub ab, und aktualisieren Sie dann die XML-Dateien im LocalAccounts Starter Pack mit Ihrem Azure AD B2C-Mandantennamen:
1. Laden Sie die .zip Datei herunter, oder klonen Sie das Repository:
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
2. Ersetzen Sie in allen Dateien im Verzeichnis "LocalAccounts " die Zeichenfolge yourtenant durch den Namen Ihres Azure AD B2C-Mandanten. Wenn beispielsweise der Name Ihres B2C-Mandanten contoso lautet, werden alle Instanzen von yourtenant.onmicrosoft.com zu contoso.onmicrosoft.com.
Öffnen Sie die Datei LocalAccounts/TrustFrameworkExtensions.xml.
Suchen Sie das ClaimsProviders-Element . Wenn es nicht vorhanden ist, fügen Sie es unter dem Stammelement hinzu. TrustFrameworkPolicy
Fügen Sie einen neuen ClaimsProvider wie folgt hinzu:

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</Item>
        <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>
        <!-- trying to add additional claim-->
        <!--Insert b2c-extensions-app application ID here, for example: 00001111-aaaa-2222-bbbb-3333cccc4444-->
        <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
        <!--Insert b2c-extensions-app application ObjectId here, for example: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb-->
        <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
        <!-- The commented key specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to sign in. -->
        <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>

      </Metadata>
      <CryptographicKeys>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </CryptographicKeys>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
        <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Legen Sie client_id mit der Trusona Authentication Cloud-Anwendungs-ID fest, die Sie zuvor in Schritt 1 aufgezeichnet haben.
Aktualisieren Sie den Abschnitt client_secret mit dem Namen des in Schritt 3 erstellten Richtlinienschlüssels. Beispiel: B2C_1A_TrusonaTacClientSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
```
Speichern Sie die Änderungen.

Schritt 5: Hinzufügen einer Benutzerreise

Zu diesem Zeitpunkt richten Sie den IdP ein, aber er ist auf keiner der Anmeldeseiten verfügbar. Wenn Sie über eine eigene benutzerdefinierte Benutzerreise verfügen, fahren Sie mit Schritt 6 fort, andernfalls erstellen Sie ein Duplikat einer vorhandenen Benutzerreise für Vorlagen wie folgt:

Öffnen Sie die LocalAccounts/TrustFrameworkBase.xml Datei aus dem Startpaket.
Suchen und kopieren Sie den gesamten Inhalt des UserJourney-Elements, das Id=SignUpOrSignIn enthält.
Öffnen Sie das LocalAccounts/TrustFrameworkExtensions.xml, und finden Sie das UserJourneys-Element. Wenn das Element nicht vorhanden ist, fügen Sie eins hinzu.
Fügen Sie den gesamten Inhalt des kopierten UserJourney-Element als untergeordnetes Element des UserJourneys-Elements ein.
Benennen Sie die Id der User Journey um. Beispiel: Id=TrusonaTacSUSI.

Schritt 6: Hinzufügen des IdP zu einem Benutzerablauf

Nachdem Sie nun über eine User Journey verfügen, fügen Sie den neuen Identitätsanbieter der User Journey hinzu.

Suchen Sie nach dem Orchestrierungsschrittelement, das Type=CombinedSignInAndSignUp enthält, oder Type=ClaimsProviderSelection in der User Journey. Es ist in der Regel der erste Orchestrierungsschritt. Das ClaimsProviderSelections-Element enthält eine Liste von IDPs, mit denen sich ein Benutzer anmelden kann. Die Reihenfolge der Elemente steuert die Reihenfolge der Anmeldeschaltflächen, die dem Benutzer angezeigt werden. Fügen Sie ein ClaimsProviderSelection-XML-Element hinzu. Legen Sie den Wert von TargetClaimsExchangeId auf einen benutzerfreundlichen Namen fest, z. B. TrusonaTacExchange.
Fügen Sie im nächsten Orchestrierungsschritt ein ClaimsExchange-Element hinzu. Legen Sie die ID auf den Wert der Zielanspruchsaustausch-ID fest. Aktualisieren Sie den Wert von TechnicalProfileReferenceId auf die ID des zuvor erstellten technischen Profils, während Sie den Anspruchsanbieter hinzufügen, TrusonaTAC-OpenIdConnectz. B. . .

Der folgende XML-Code veranschaulicht die Orchestrierungsschritte einer Benutzerreise mit dem Identitätsanbieter:

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <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 (we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" 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>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </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>

Erfahren Sie mehr über User Journeys.

Schritt 7: Konfigurieren der Richtlinie für die vertrauende Seite

Die Richtlinie der vertrauenden Seite, z. B. SignUpSignIn.xml, gibt die User Journey an, die von Azure AD B2C ausgeführt wird. Suchen Sie innerhalb der vertrauenden Seite das Element DefaultUserJourney. Aktualisieren Sie die ReferenceId so, dass sie mit der Benutzerreise-ID übereinstimmt, in der Sie den Identitätsanbieter hinzugefügt haben.

Im folgenden Beispiel wird für den Trusona Authentication Cloud Benutzerablauf die ReferenceId auf TrusonaTacSUSI festgelegt.

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

Schritt 8: Hochladen der benutzerdefinierten Richtlinie

Melden Sie sich beim Azure-Portal an.
Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie das Symbol Einstellungen im Menü oben aus, um über das Menü Verzeichnisse + Abonnements zu Ihrem Azure AD B2C-Mandanten zu wechseln.
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, und laden Sie dann die beiden geänderten Richtliniendateien in der folgenden Reihenfolge hoch: die Erweiterungsrichtlinie, z.B. TrustFrameworkExtensions.xml, dann die Richtlinie der vertrauenden Seite, z.B. SignUpOrSignin.xml.

Schritt 9: Testen Sie Ihre benutzerdefinierte Richtlinie

Wählen Sie in Ihrem Azure AD B2C-Mandanten unter "Richtlinien" die Option "Identity Experience Framework" aus.
Wählen Sie unter "Benutzerdefinierte Richtlinien" "TrusonaTacSUSI" aus.
Wählen Sie für "Anwendung" die Webanwendung aus, die Sie zuvor als Teil der Voraussetzungen dieses Artikels registriert haben. zum Beispiel jwt ms. Als Antwort-URL sollte https://jwt.ms angezeigt werden.
Wählen Sie Jetzt ausführen aus. Ihr Browser sollte zur Anmeldeseite der Trusona Authentication Cloud umgeleitet werden.
Es wird ein Anmeldebildschirm angezeigt; am unteren Rand sollte eine Schaltfläche sein, um die Trusona Authentication Cloud-Authentifizierung zu verwenden.
Sie sollten zur Trusona Authentication Cloud umgeleitet werden. Dem Benutzer wird eine Anmeldewebseite angezeigt, die nach ihrem Benutzernamen fragt – in der Regel eine E-Mail-Adresse. Wenn das Konto des Benutzers in der Trusona Authentication Cloud nicht gefunden wird, wird eine Antwort an den Browser gesendet, der einen WebAuthn-Registrierungsprozess auf dem Gerät initiiert. Andernfalls wird eine Antwort an den Browser gesendet, der einen WebAuthn-Authentifizierungsprozess startet. Der Benutzer wird aufgefordert, die zu verwendenden Anmeldeinformationen auszuwählen. Der Schlüssel ist der Domäne der Webanwendung oder einem Hardwaresicherheitsschlüssel zugeordnet. Sobald der Benutzer eine Anmeldeinformationen auswählt, fordert das Betriebssystem den Benutzer auf, eine biometrische, Kennung oder PIN zu verwenden, um seine Identität zu bestätigen. Dadurch wird die sichere Enklave/vertrauenswürdige Ausführungsumgebung entsperrt, die eine Authentifizierungsbehauptung generiert, die vom privaten Schlüssel signiert ist, der den ausgewählten Anmeldedaten zugeordnet ist.
Wenn der Anmeldevorgang erfolgreich ist, wird Ihr Browser zu https://jwt.ms umgeleitet, wo der Inhalt des von Azure AD B2C zurückgegebenen Tokens angezeigt wird.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln: