Konfigurieren von Trusona Authentication Cloud mit Azure Active Directory B2C

Artikel
01/26/2024

In diesem Beispieltutorial erfahren Sie, wie Sie die Azure AD B2C-Authentifizierung mit Trusona Authentication Cloud integrieren. Es handelt sich um einen cloudbasierten Dienst, der es Benutzern ermöglicht, sich mit einer Tap-and-Go (Tippen und los)-Erfahrung zu authentifizieren, ohne dass eine mobile Authentifikator-App erforderlich ist.

Die Integration von Trusona Authentication Cloud in Azure AD B2C bietet folgende Nutzen:

Bereitstellen einer starken Authentifizierung mit einer besseren Benutzererfahrung
- Zufriedenere Benutzer, die Online mehr ausgeben
- Geringere Fluktuation und weniger Abgänge, höhere Einnahmen
- Höhere Kundenbindung, Lebenszeitwert (Lifetime Value, LTV)
Geringere Kosten für den Betrieb des Unternehmens
- Reduzierte Kontoübernahmen und Kontofreigaben
- Reduzierter Betrug und weniger manuelle Betrugsanalyseaktionen
- Reduzierte Ausgaben für das Outsourcing manueller Überprüfungen
Elimination von Kennwörtern
- Keine Kennwortzurücksetzungen mehr
- Reduzierte Callcenter-Beschwerden
- Schnelle, einfache, reibungslose Anmeldungen mithilfe von Hauptschlüsseln

Voraussetzungen

Zunächst benötigen Sie Folgendes:

Ein Trusona Authentication Cloud-Testkonto. Kontaktieren Sie Trusona, um ein Konto anzufordern.
Ein Azure-Abonnement. Falls Sie über kein Abonnement verfügen, können Sie ein kostenloses Azure-Konto verwenden.
Einen Azure AD B2C-Mandanten, der mit Ihrem Azure-Abonnement verknüpft ist.

Vervollständigen Sie die Schritte im Artikel Erste Schritte mit benutzerdefinierten Richtlinien in Azure AD B2C aus.

Beschreibung des Szenarios

Webauthentifizierungsstandard – WebAuthn implementiert moderne Betriebssysteme und Browser, um die Authentifizierung über Fingerdruck, Windows Hello oder externe FIDO-Geräte wie USB, Bluetooth und OTP zu unterstützen.

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

Einer kombinierten Azure AD B2C-Anmelde- und Registrierungsrichtlinie.
Trusona Authentication Cloud hat Azure AD B2C als IdP hinzugefügt.

Screenshot shows Trusona architecture diagram.

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 um.
4.	Dem Benutzer wird eine Anmeldewebseite präsentiert, auf der nach seinem Benutzernamen gefragt wird – 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 Benutzerkonto in der Trusona Authentication Cloud nicht gefunden wird, wird eine Antwort an den Browser gesendet, der einen WebAuthn-Registrierungsvorgang auf dem Gerät einleitet. Andernfalls wird eine Antwort an den Browser gesendet, der einen WebAuthn-Authentifizierungsprozess startet.
6.	Der Benutzer wird aufgefordert, eine zu verwendende Anmeldeinformation auszuwählen. Der Hauptschlüssel ist der Domäne der Webanwendung oder einem Hardwaresicherheitsschlüssel zugeordnet. Sobald der Benutzer eine Anmeldeinformation auswählt, fordert das Betriebssystem den Benutzer auf, ein biometrisches Merkmal, einen Passcode oder eine PIN zu verwenden, um seine Identität zu bestätigen. Dadurch wird die Secure Enclave/Trusted Execution-Umgebung entsperrt, die eine Assertionsanweisung für die Authentifizierung generiert, die mit dem privaten Schlüssel signiert wird, welcher der ausgewählten Anmeldeinformation zugeordnet ist.
7.	Die Assertionsanweisung für die Authentifizierung wird zur Überprüfung an den Trusona-Clouddienst zurückgegeben.
8.	Nach der Überprüfung erstellt Trusona Authentication Cloud (der IdP) ein OIDC-ID-Token und leitet es dann an Azure AD B2C (der Dienstanbieter) weiter. Azure AD B2C überprüft die Signatur des Tokens und den Aussteller anhand der Werte im OpenID-Ermittlungsdokument von Trusona. Diese Details wurden während der IdP-Einrichtung konfiguriert. Nach der Überprüfung gibt Azure AD B2C eine OIDC-id_token aus (abhängig vom Bereich) und leitet den Benutzer mit dem Token zurück zur initiierenden Anwendung.
9.	Die Webanwendung (oder die Entwicklerbibliotheken, die sie zum Implementieren der Authentifizierung verwendet) 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 verbraucht.
10.	Nach der Überprüfung wird dem Benutzer der Zugriff gewährt/verweigert.

Schritt 1: Onboarding durchführen 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 aus, um OIDC zu aktivieren.
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 zur 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 wird Trusona Sie dem richtigen Konto zuweisen und Ihre Berechtigungen auf Lesen/Schreiben erhöhen, basierend auf der Zugriffssteuerungsrichtlinie Ihrer Organisation für Portalbenutzer.
2. Der ursprüngliche Domänenname von 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 werden. In diesem Tutorial erfahren Sie, wie Sie eine Webanwendung mithilfe des Azure-Portals registrieren. Für Testzwecke wie in diesem Tutorial können Sie https://jwt.ms registrierten. Dabei handelt es sich um eine Microsoft-Webanwendung, die den decodierten Inhalt eines Tokens anzeigt (der Inhalt des Tokens verlässt niemals Ihren Browser). Zum Registrieren einer Webanwendung bei Ihrem Azure AD B2C-Mandanten können Sie unsere neue einheitliche App-Registrierungserfahrung verwenden.

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 unter Name 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 Benutzern mit Benutzerflows) aus.
Wählen Sie unter Umleitungs-URI die Option Web aus, und geben Sie https://jwt.ms in das URL-Textfeld ein.

Der Umleitungs-URI ist der Endpunkt, an den der Autorisierungsserver, in diesem Fall Azure AD B2C, den Benutzer sendet. Nach Abschluss der Interaktion mit dem Benutzer wird bei erfolgreicher Autorisierung ein Zugriffstoken oder ein 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 in diesem Tutorial können Sie ihn auf https://jwt.ms festlegen. Dabei handelt es sich um eine Microsoft-Webanwendung, die den decodierten Inhalt eines Tokens anzeigt (der Inhalt des Tokens verlässt niemals 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.

Für Umleitungs-URIs gelten die folgenden Einschränkungen:
- 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 als Teil des Pfads .../abc/response-oidc 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. Beispielsweise könnten https://contoso.com/auth-response und https://contoso.com/auth-response/ in Ihrer Anwendung als nicht übereinstimmende URLs behandelt werden.
Aktivieren Sie unter Berechtigungen das Kontrollkästchen Administratoreinwilligung für openid- und offline_access-Berechtigungen erteilen.
Wählen Sie Registrieren.

Aktivieren der impliziten Genehmigung von ID-Token

Wenn Sie diese App registrieren und mit https://jwt.ms/ konfigurieren, um einen Benutzerflow oder eine benutzerdefinierte Richtlinie zu testen, müssen Sie den Flow zur impliziten Genehmigung in der App-Registrierung aktivieren:

Wählen Sie im linken Menü unter Verwalten die Option Authentifizierung aus.
Aktivieren Sie unter Implizite Genehmigung und Hybridflows die Kontrollkästchen ID-Token (für implizite und Hybridflows verwendet).
Wählen Sie Speichern aus.

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

Melden Sie sich beim Azure-Portal als globaler Administrator Ihres 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.
Klicken Sie links oben im Azure-Portal auf Alle Dienste, suchen Sie nach Azure AD B2C, und klicken Sie darauf.
Navigieren Sie zu Dashboard>Azure Active Directory B2C>Identitätsanbieter.
Wählen Sie Identitätsanbieter aus.
Wählen Sie Hinzufügen.

Konfigurieren eines IdP

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

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

Eigenschaft	Wert
Metadaten-URL	`https://authcloud.trusona.net/.well-known/openid-configuration`
Client-ID	verfügbar im Trusona Authentication Cloud-Portal
Geheimer Clientschlüssel	verfügbar im Trusona Authentication Cloud-Portal
`Scope`	E-Mail-Adresse aus OpenID-Profil
Antworttyp	code
Antwortmodus	form_post

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

Eigenschaft Wert

UserID sub

`Display name` nickname

Vorname given_name

Surname family_name

Antwortmodus email
Wählen Sie OK aus, um die Einrichtung für Ihren neuen OIDC-IdP abzuschließen.

Eigenschaft	Wert
UserID	sub
`Display name`	nickname
Vorname	given_name
Surname	family_name
Antwortmodus	email

Schritt 4: Erstellen einer Richtlinie für Benutzerflows

Sie sollten Trusona jetzt als neuer OpenID Connect-Identitätsanbieter unter Ihren B2C-IdPs aufgeführt sehen.

Wählen Sie auf Ihrem Azure AD B2C-Mandanten unter Richtlinien die Option Benutzerflows aus.
Wählen Sie die Option Neuer Benutzerflow aus.
Wählen Sie Registrierung und Anmeldung, dann eine Version und anschließend Erstellen aus.
Geben Sie einen Namen für die Richtlinie ein.
Wählen Sie im Abschnitt Identitätsanbieter Ihren neu erstellten Trusona Authentication Cloud-Identitätsanbieter aus.

Hinweis

Da es sich bei Trusona quasi um eine mehrstufige Authentifizierung handelt, sollten Sie die Option für die mehrstufige Authentifizierung deaktiviert lassen.
Klicken Sie auf Erstellen.
Wählen Sie unter Benutzerattribute und Ansprüche die Option Mehr anzeigen aus. Wählen Sie im Formular mindestens ein Attribut aus, das Sie oben bei der Einrichtung Ihres Identitätsanbieters angegeben haben.
Klicken Sie auf OK.

Schritt 5: Testen des Benutzerflows

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

a. Anwendung: Wählen Sie die registrierte App aus, beispielsweise „jwt ms“.

b. Antwort-URL: Wählen Sie die Umleitungs-URL aus, beispielsweise https://jwt.ms.
Wählen Sie Benutzerflow ausführen aus. Sie sollten zur Trusona Authentication Cloud umgeleitet werden. Dem Benutzer wird eine Anmeldewebseite präsentiert, auf der nach seinem Benutzernamen gefragt wird – in der Regel eine E-Mail-Adresse. Wenn das Benutzerkonto in Trusona Authentication Cloud nicht gefunden wird, wird eine Antwort an den Browser gesendet, der einen WebAuthn-Registrierungsvorgang auf dem Gerät initiiert. Andernfalls wird eine Antwort an den Browser gesendet, der einen WebAuthn-Authentifizierungsprozess startet. Der Benutzer wird aufgefordert, eine zu verwendende Anmeldeinformation auszuwählen. Der Hauptschlüssel ist der Domäne der Webanwendung oder einem Hardwaresicherheitsschlüssel zugeordnet. Sobald der Benutzer eine Anmeldeinformation auswählt, fordert das Betriebssystem den Benutzer auf, ein biometrisches Merkmal, einen Passcode oder eine PIN zu verwenden, um seine Identität zu bestätigen. Dadurch wird die Secure Enclave/Trusted Execution-Umgebung entsperrt, die eine Assertionsanweisung für die Authentifizierung generiert, die mit dem privaten Schlüssel signiert wird, welcher der ausgewählten Anmeldeinformation zugeordnet ist. Azure AD B2C überprüft die Trusona-Authentifizierungsantwort und gibt ein OIDC-Token aus. Der Benutzer wird zurück zur initiierenden Anwendung weitergeleitet, z. B. https://jwt.ms, die den Inhalt des von Azure AD B2C zurückgegebenen Tokens anzeigt.

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

Speichern Sie den geheimen Clientschlüssel, den Sie 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 links oben im Azure-Portal die Option Alle Dienste aus, suchen Sie nach Azure AD B2C, und wählen Sie dann diese Option aus.
Wählen Sie auf der Seite „Übersicht“ die Option Framework für die Identitätsfunktion aus.
Klicken Sie erst auf Richtlinienschlüssel und anschließend auf Hinzufügen.
Wählen Sie unter Optionen die Option Manuell aus.
Geben Sie einen Namen für den Richtlinienschlüssel ein. Beispiel: TrusonaTacClientSecret. Dem Namen Ihres Schlüssels wird automatisch das Präfix B2C_1A_ hinzugefügt.
Geben Sie im Feld Geheimnis den geheimen Clientschlüssel ein, den Sie zuvor notiert haben.
Wählen Sie für Schlüsselverwendung die Option Signature aus.
Klicken Sie auf Erstellen.

Schritt 4: Konfigurieren von Trusona Authentication Cloud als ein IdP

Tipp

An dieser Stelle sollten Sie die Azure AD B2C-Richtlinie konfiguriert haben. Befolgen Sie andernfalls die Anweisungen zum Einrichten Ihres Azure AD B2C-Mandanten und zum Konfigurieren von Richtlinien.

Damit sich Benutzer mit Trusona Authentication Cloud anmelden können, müssen Sie Trusona als Anspruchsanbieter definieren, mit dem Azure AD B2C über einen Endpunkt kommunizieren kann. Der Endpunkt stellt eine Menge von Ansprüchen bereit, mit denen Azure AD B2C überprüft, ob sich ein bestimmter Benutzer mit einem Hauptschlüssel oder einem Hardwaresicherheitsschlüssel auf seinem Gerät authentifiziert hat, um die Identität des Benutzers zu beweisen.

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

Holen Sie sich die Starter Packs für benutzerdefinierte Richtlinien-von GitHub, und aktualisieren Sie dann die XML-Dateien im Starter Pack „LocalAccounts“ mit dem Namen Ihres Azure AD B2C-Mandanten:
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 z. B. der Name des B2C-Mandanten contoso lautet, werden alle Instanzen von yourtenant.onmicrosoft.com in contoso.onmicrosoft.com geändert.
Öffnen Sie die Datei LocalAccounts/TrustFrameworkExtensions.xml.
Suchen Sie nach dem Element ClaimsProviders. Falls das Element nicht vorhanden sein sollte, fügen Sie es unter dem Stammelement TrustFrameworkPolicy hinzu.
Fügen Sie einen neuen Anspruchsanbieter hinzu, der dem nachfolgend abgebildeten ähnelt:

<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">00000000-0000-0000-0000-000000000000</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: 11111111-1111-1111-1111-111111111111-->
        <Item Key="11111111-1111-1111-1111-111111111111"></Item>
        <!--Insert b2c-extensions-app application ObjectId here, for example: 22222222-2222-2222-2222-222222222222-->
        <Item Key="11111111-1111-1111-1111-111111111111"></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/11111111-1111-1111-1111-111111111111</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 auf die Trusona Authentication Cloud-Anwendungs-ID fest, die Sie zuvor in Schritt 1 notiert haben.
Aktualisieren Sie den Abschnitt client_secret mit dem Namen des in Schritt 3 erstellten Richtlinienschlüssels. Zum Beispiel B2C_1A_TrusonaTacClientSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacClientSecret" />
```
Speichern Sie die Änderungen.

Schritt 5: Hinzufügen einer User Journey

Zu diesem Zeitpunkt ist der Identitätsanbieter eingerichtet, ist aber noch nicht auf Anmeldeseiten verfügbar. Fahren Sie mit Schritt 6 fort, wenn Sie über eine eigene benutzerdefinierte User Journey verfügen. Erstellen Sie andernfalls ein Duplikat einer vorhandenen User Journey-Vorlage wie folgt:

Öffnen Sie die Datei LocalAccounts/TrustFrameworkBase.xml aus dem Starter Pack.
Suchen und kopieren Sie den gesamten Inhalt des UserJourney-Elements, das Id=SignUpOrSignIn enthält.
Öffnen Sie die Datei LocalAccounts/TrustFrameworkExtensions.xml, und suchen Sie nach dem Element UserJourneys. Wenn das Element nicht vorhanden ist, fügen Sie ein solches 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.

Teil 6: Hinzufügen des IdP zu einer User Journey

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. Dies ist in der Regel der erste Orchestrierungsschritt. Das ClaimsProviderSelections-Element enthält eine Liste mit Identitätsanbietern, mit denen sich ein Benutzer anmelden kann. Die Reihenfolge der Elemente gibt die Reihenfolge der Anmeldeschaltflächen vor, die dem Benutzer angezeigt werden. Fügen Sie ein ClaimsProviderSelection-XML-Element hinzu. Legen Sie den Wert von TargetClaimsExchangeId auf einen Anzeigenamen wie TrusonaTacExchange fest.
Fügen Sie im nächsten Orchestrierungsschritt ein ClaimsExchange-Element hinzu. Legen Sie die Id auf den Wert der Zielanspruchsaustausch-ID fest. Ändern Sie den Wert von TechnicalProfileReferenceId in die ID des technischen Profils, das Sie zuvor beim Hinzufügen des Anspruchsanbieters erstellt haben, z. B. TrusonaTAC-OpenIdConnect.

Der folgende XML-Code veranschaulicht Orchestrierungsschritte einer User Journey 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>

Weitere Informationen zu User Journeys.

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

Die Richtlinie für die vertrauende Seite, z. B. SignUpSignIn.xml, gibt die User Journey an, die Azure AD B2C ausführt. Suchen Sie auf der vertrauenden Seite das Element DefaultUserJourney. Aktualisieren Sie ReferenceId auf die ID der User Journey, in der Sie den Identitätsanbieter hinzugefügt haben.

Im folgenden Beispiel wird die ReferenceId für die User Journey Trusona Authentication Cloud 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 klicken Sie darauf.
Klicken Sie unter „Richtlinien“ auf Identity Experience Framework.
Wählen Sie Benutzerdefinierte Richtlinie hochladen aus, und laden Sie dann die beiden geänderten Richtliniendateien in der folgenden Reihenfolge hoch: zuerst die Erweiterungsrichtlinie (z. B. TrustFrameworkExtensions.xml) und dann die Richtlinie für die vertrauende Seite (z. B. SignUpOrSignin.xml).

Schritt 9: 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 Option TrusonaTacSUSI aus.
Wählen Sie unter Anwendung die Webanwendung aus, die Sie zuvor als Bestandteil der Voraussetzungen dieses Artikels registriert haben. Beispiel: jwt ms. Als Antwort-URL sollte https://jwt.ms angezeigt werden.
Wählen Sie Jetzt ausführen aus. Ihr Browser sollte zur Trusona Authentication Cloud-Anmeldeseite umgeleitet werden.
Ein Anmeldebildschirm wird angezeigt. Am unteren Rand sollte sich eine Schaltfläche für die Verwendung der Trusona Authentication Cloud-Authentifizierung befinden.
Sie sollten zur Trusona Authentication Cloud umgeleitet werden. Dem Benutzer wird eine Anmeldewebseite präsentiert, auf der nach seinem Benutzernamen gefragt wird – in der Regel eine E-Mail-Adresse. Wenn das Benutzerkonto in der Trusona Authentication Cloud nicht gefunden wird, wird eine Antwort an den Browser gesendet, der einen WebAuthn-Registrierungsvorgang auf dem Gerät einleitet. Andernfalls wird eine Antwort an den Browser gesendet, der einen WebAuthn-Authentifizierungsprozess startet. Der Benutzer wird aufgefordert, eine zu verwendende Anmeldeinformation auszuwählen. Der Hauptschlüssel ist der Domäne der Webanwendung oder einem Hardwaresicherheitsschlüssel zugeordnet. Sobald der Benutzer eine Anmeldeinformation auswählt, fordert das Betriebssystem den Benutzer auf, ein biometrisches Merkmal, einen Passcode oder eine PIN zu verwenden, um seine Identität zu bestätigen. Dadurch wird die Secure Enclave/Trusted Execution-Umgebung entsperrt, die eine Assertionsanweisung für die Authentifizierung generiert, die mit dem privaten Schlüssel signiert wird, welcher der ausgewählten Anmeldeinformation zugeordnet ist.
Wenn der Anmeldevorgang erfolgreich verlaufen ist, wird der Browser an https://jwt.ms umgeleitet und dadurch der Inhalt des von Azure AD B2C zurückgegebenen Tokens angezeigt.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Artikeln: