Konfigurieren von Asignio mit Azure Active Directory B2C für die Multi-Faktor-Authentifizierung

Artikel
01/26/2024

Erfahren Sie, wie Sie die Microsoft Entra ID-Authentifizierung (Azure AD B2C) in Asignio integrieren. Mit dieser Integration können Sie Kunden eine kennwortlose, weiche biometrische und Multi-Faktor-Authentifizierung ermöglichen. Asignio verwendet die patentierte Asignio-Signatur und die Live-Gesichtsüberprüfung für die Benutzerauthentifizierung. Durch die veränderliche biometrische Signatur werden Kennwörter, Betrug, Phishing und Wiederverwendung von Anmeldeinformationen über die Omnikanalauthentifizierung reduziert.

Voraussetzungen

Wählen Sie eine Richtlinientypauswahl aus, um das Richtlinientypsetup anzugeben. Azure AD B2C verfügt über zwei Methoden, um zu definieren, wie Benutzer mit Ihren Anwendungen interagieren:

Vordefinierte Benutzerflows
Konfigurierbare benutzerdefinierte Richtlinien

Die in diesem Artikel beschriebenen Schritte unterscheiden sich von Methode zu Methode.

Weitere Informationen:

Voraussetzungen

Ein Azure-Abonnement.
Wenn Sie kein Konto haben, können Sie ein kostenloses Azure-Konto erstellen

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.
Eine Asignio Client-ID und ein geheimer Clientschlüssel, die von Asignio ausgestellt werden.
Sie erhalten diese Token bei der Registrierung Ihrer mobilen oder Webanwendungen bei Asignio.

Für benutzerdefinierte Richtlinien

Schließen Sie das Tutorial: Erstellen von Benutzerflows und benutzerdefinierten Richtlinien in Azure AD B2C ab.

Beschreibung des Szenarios

Die Integration umfasst die folgenden Komponenten:

Azure AD B2C – der Autorisierungsserver zum Überprüfen von Benutzeranmeldeinformationen
Web- oder mobile Anwendungen: zum Sichern mit Asignio MFA
Asignio-Webanwendung:: Biometrische Signatursammlung auf dem Touchgerät des Benutzers

Das folgende Diagramm veranschaulicht die Implementierung.

Diagramm, das die Implementierungsarchitektur zeigt.

Der Benutzer öffnet die Azure AD B2C-Anmeldeseite in der mobilen oder Webanwendung und meldet sich dann an oder registriert sich.
Azure AD B2C leitet den Benutzer mithilfe einer OIDC-Anforderung (OpenID Connect) an Asignio um.
Der Benutzer wird für die biometrische Anmeldung an die Asignio-Webanwendung umgeleitet. Wenn der Benutzer seine Asignio-Signatur nicht registriert hat, kann er ein einmaliges SMS-Kennwort (OTP) zum Authentifizieren verwenden. Nach der Authentifizierung erhält der Benutzer einen Registrierungslink, um seine Asignio-Signatur zu erstellen.
Der Benutzer authentifiziert sich mit seiner Asignio-Signatur und Gesichtsüberprüfung oder einer Sprach- und Gesichtsüberprüfung.
Die Abfrageantwort geht an Asignio.
Asignio gibt die OIDC-Antwort an die Azure AD B2C-Anmeldung zurück.
Azure AD B2C sendet eine Authentifizierungsüberprüfungsanforderung an Asignio, um den Empfang der Authentifizierungsdaten zu bestätigen.
Dem Benutzer wird der Zugriff auf die Anwendung gewährt oder verweigert.

Konfigurieren einer Anwendung mit Asignio

Die Konfiguration einer Anwendung mit Asignio erfolgt über die Asignio Partner Administration-Website.

Gehen Sie auf asignio.com und rufen Sie die Seite Asignio Partner Administration auf, um Zugriff für Ihre Organisation anzufordern.
Melden Sie sich mit Anmeldeinformationen bei Asignio Partner Administration an.
Erstellen Sie einen Eintrag für die Azure AD B2C-Anwendung unter Verwendung Ihres Azure AD B2C-Mandanten. Wenn Sie Azure AD B2C mit Asignio verwenden, verwaltet Azure AD B2C verbundenen Anwendungen. Asignio-Apps stellen Apps im Azure-Portal dar.
Generieren Sie auf der Asignio Partner Administration-Website eine Client-ID und einen geheimen Clientschlüssel.
Notieren und speichern Sie die Client-ID und den geheimen Clientschlüssel. Sie benötigen beides später noch. Geheime Clientschlüssel werden nicht von Asignio gespeichert.
Geben Sie die Umleitungs-URI in Ihrer Website ein, zu der der Benutzer nach der Authentifizierung zurückgeleitet wird. Verwenden Sie das folgende URI-Muster.

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

Laden Sie ein Unternehmenslogo hoch. Es wird bei der Asignio-Authentifizierung angezeigt, wenn sich Benutzer anmelden.

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

Für dieses Tutorial 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 das Tutorial: Registrieren einer Webanwendung in Azure Active Directory B2C ab.

Konfigurieren von Asignio als Identitätsanbieter in Azure AD B2C

Verwenden Sie für die folgenden Anweisungen den Microsoft Entra-Mandanten mit dem Azure-Abonnement.

Melden Sie sich beim Azure-Portal als globaler Administrator des Azure AD B2C-Mandanten an.
Wählen Sie auf der Symbolleiste des Azure-Portals Verzeichnisse + Abonnements aus.
Suchen Sie auf der Seite Portaleinstellungen | Verzeichnisse + Abonnements in der Liste Verzeichnisname Ihr Microsoft Entra-Verzeichnis.
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.
Suchen Sie im Azure-Portal nach Azure AD B2C, und wählen Sie diese Option dann aus.
Wählen Sie im linken Bereich Identitätsanbieter aus.
Wählen Sie Neuer OpenID Connect-Anbieter aus.
Wählen Sie Identitätsanbietertyp>OpenID Connect aus.
Geben Sie unter Name die Asignio-Anmeldung oder einen gewünschten Namen ein.
Geben Sie unter Metadaten-URL die URL https://authorization.asignio.com/.well-known/openid-configuration ein.
Geben Sie unter Client-ID die von Ihnen generierte Client-ID ein.
Geben Sie unter Geheimer Clientschlüssel den von Ihnen generierten geheimen Clientschlüssel ein.
Verwenden Sie für Bereich das OpenID-E-Mail-Profil.
Verwenden Sie für Antworttyp den Wert Code.
Verwenden Sie als Antwortmodus die Option Abfrage.
Verwenden Sie für Domänenhinweise die Option https://asignio.com.
Klicken Sie auf OK.
Wählen Sie Ansprüche dieses Identitätsanbieters zuordnen aus.
Verwenden Sie für Benutzer-ID die Option sub.
Verwenden Sie für Anzeigename die Option Name.
Verwenden Sie für Vorname den Wert given_name.
Verwenden Sie für Nachname den Wert family_name.
Verwenden Sie für E-Mail die Option Email.
Wählen Sie Speichern aus.

Erstellen einer Benutzerflowrichtlinie

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 den Benutzerflowtyp Registrierung und Anmeldung aus.
Wählen Sie Empfohlene Version aus.
Klicken Sie auf Erstellen.
Geben Sie einen Namen für den Benutzerflow ein, z. B. AsignioSignupSignin.
Wählen Sie unter Identitätsanbieter für Lokale Konten die Option Keine aus. Diese Aktion deaktiviert die E-Mail- und Kennwortauthentifizierung.
Wählen Sie unter Benutzerdefinierte Identitätsanbieter den erstellten Asignio-Identitätsanbieter aus.
Klicken Sie auf Erstellen.

Testen des Benutzerflows

Wählen Sie in Ihrem Azure AD B2C-Mandanten die Option Benutzerflows aus.
Wählen Sie den erstellten Benutzerflow aus.
Wählen Sie als Anwendung die Webanwendung aus, die Sie registriert haben. Die Antwort-URL lautet https://jwt.ms.
Wählen Sie Benutzerflow ausführen aus.
Der Browser wird an die Anmeldeseite von Asignio umgeleitet.
Ein Anmeldebildschirm wird angezeigt.
Wählen Sie unten Asignio-Authentifizierung aus.

Wenn Sie über eine Asignio-Signatur verfügen, füllen Sie die Eingabeaufforderung zur Authentifizierung aus. Wenn nicht, geben Sie die Gerätetelefonnummer an, um sich per SMS OTP zu authentifizieren. Verwenden Sie den Link, um Ihre Asignio-Signatur zu registrieren.

Der Browser wird an https://jwt.ms umgeleitet. Die von Azure AD B2C zurückgegebenen Tokeninhalte werden angezeigt.

Erstellen eines Asignio-Richtlinienschlüssels

Speichern Sie den generierten geheimen Clientschlüssel im 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.
Suchen Sie auf der Seite Portaleinstellungen | Verzeichnisse + Abonnements in der Liste Verzeichnisname Ihr Azure AD B2C-Verzeichnis.
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 auf der Seite „Übersicht“ die Option Framework für die Identitätsfunktion 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 ein, den Sie sich notiert haben.
Wählen Sie unter SchlüsselverwendungSignatur aus.
Klicken Sie auf Erstellen.

Konfigurieren von Asignio als Identitätsanbieter

Tipp

Bevor Sie beginnen, stellen Sie sicher, dass die Azure AD B2C-Richtlinie konfiguriert ist. Falls nicht, befolgen Sie die Anweisungen im Starter Pack für benutzerdefinierte Richtlinien.

Damit sich Benutzer mit Asignio anmelden können, definieren Sie Asignio 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 ID auf dem Gerät verwendet.

Hinzufügen von Asignio als Anspruchsanbieter

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:

Laden Sie die ZIP-Datei active-directory-b2c-custom-policy-starterpack herunter, oder klonen Sie das Repository:
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
Ersetzen Sie in allen Dateien im Verzeichnis LocalAccounts die Zeichenfolge yourtenant durch den Namen Ihres Azure AD B2C-Mandanten.
Öffnen Sie die Datei LocalAccounts/ TrustFrameworkExtensions.xml.
Suchen Sie nach dem Element ClaimsProviders. Wenn keine vorhanden ist, fügen Sie sie unter dem Stammelement „TrustFrameworkPolicy“ hinzu.

Fügen Sie ein neues ClaimsProvider-Element wie im folgenden Beispiel hinzu:

 <ClaimsProvider>
   <Domain>contoso.com</Domain>
   <DisplayName>Asignio</DisplayName>
   <TechnicalProfiles>
     <TechnicalProfile Id="Asignio-Oauth2">
       <DisplayName>Asignio</DisplayName>
       <Description>Login with your Asignio account</Description>
       <Protocol Name="OAuth2" />
       <Metadata>
         <Item Key="ProviderName">authorization.asignio.com</Item>
         <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
         <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
         <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
         <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
         <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
         <Item Key="HttpBinding">POST</Item>
         <Item Key="scope">openid profile email</Item>
         <Item Key="UsePolicyInRedirectUri">0</Item>
         <!-- Update the Client ID below to the Asignio Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</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="22222222-2222-2222-2222-222222222222"></Item>
         <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
         <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
         <!-- The commented key below 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>
         <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
       </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://authorization.asignio.com" />
         <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
         <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
         <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
         <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
         <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="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 Asignio-Anwendungs-ID, die Sie sich notiert haben, fest.
Aktualisieren Sie den Abschnitt client_secret mit dem Richtlinienschlüssel, den Sie erstellt haben. Zum Beispiel B2C_1A_AsignioSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
```
Speichern Sie die Änderungen.

Hinzufügen einer User Journey

Der Identitätsanbieter befindet sich nicht auf den Anmeldeseiten.

Wenn Sie über eine benutzerdefinierte User Journey verfügen, fahren Sie mit Konfigurieren der Richtlinie der vertrauenden Seite fort, andernfalls kopieren Sie eine User Journey-Vorlage:
Öffnen Sie im Starter-Paket die Datei LocalAccounts/ TrustFrameworkBase.xml.
Suchen und kopieren Sie den Inhalt des UserJourney-Elements, das Id=SignUpOrSignIn enthält.
Öffnen Sie die Datei LocalAccounts/ TrustFrameworkExtensions.xml.
Suchen Sie das Element UserJourneys. Wenn keines vorhanden ist, fügen Sie eines hinzu.
Fügen Sie die Inhalte des UserJourney-Elements als untergeordnetes Element des UserJourneys-Elements ein.]
Benennen Sie die ID der User Journey um. Beispielsweise Id=AsignioSUSI.

Weitere Informationen: User Journeys

Hinzufügen des Identitätsanbieters zu einer User Journey

Fügen Sie der User Journey den neuen Identitätsanbieter 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 Identitätsanbieterliste für die Benutzeranmeldung. 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.
Ändern Sie den Wert von TechnicalProfileReferenceId in die ID des technischen Profils, das Sie erstellt haben.

Der folgende XML-Code veranschaulicht die User Journey-Orchestrierung mit dem Identitätsanbieter.

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <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="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <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 (i.e. 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>

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, in der Sie den Identitätsanbieter hinzugefügt haben.

Im folgenden Beispiel wird die ReferenceId für die User Journey AsignioSUSI auf AsignioSUSI festgelegt:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="AsignioSUSI" />
        <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>

Hochladen der benutzerdefinierten Richtlinie

Melden Sie sich beim Azure-Portal an.
Wählen Sie auf der Symbolleiste des Portals die Option Verzeichnisse und Abonnements aus.
Suchen Sie auf der Seite Portaleinstellungen | Verzeichnisse + Abonnements in der Liste Verzeichnisname Ihr Azure AD B2C-Verzeichnis.
Wählen Sie Wechseln aus.
Suchen Sie im Azure-Portal nach Azure AD B2C, und wählen Sie diese Option dann aus.
Klicken Sie unter „Richtlinien“ auf Identity Experience Framework.
Wählen Sie Benutzerdefinierte Richtlinie hochladen aus.
Laden Sie die beiden von Ihnen geänderten Richtliniendateien in dieser Reihenfolge hoch:

Erweiterungsrichtlinie, z. B. TrustFrameworkExtensions.xml
Richtlinie für die vertrauende Seite z. B. SignUpOrSignin.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 AsignioSUSI 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 an die Anmeldeseite von Asignio umgeleitet.
Ein Anmeldebildschirm wird angezeigt.
Wählen Sie unten Asignio-Authentifizierung aus.

Wenn Sie über eine Asignio-Signatur verfügen, werden Sie aufgefordert, sich mit Ihrer Asignio-Signatur zu authentifizieren. Wenn nicht, geben Sie die Gerätetelefonnummer an, um sich per SMS OTP zu authentifizieren. Verwenden Sie den Link, um Ihre Asignio-Signatur zu registrieren.

Der Browser wird an https://jwt.ms umgeleitet. Die von Azure AD B2C zurückgegebenen Tokeninhalte werden angezeigt.

Freigeben über

Konfigurieren von Asignio mit Azure Active Directory B2C für die Multi-Faktor-Authentifizierung

Voraussetzungen

Voraussetzungen

Für benutzerdefinierte Richtlinien

Beschreibung des Szenarios

Konfigurieren einer Anwendung mit Asignio

Registrieren einer Webanwendung in Azure AD B2C

Registrieren Sie eine Webanwendung, und aktivieren Sie die implizite Genehmigung von ID-Token.

Konfigurieren von Asignio als Identitätsanbieter in Azure AD B2C

Erstellen einer Benutzerflowrichtlinie

Testen des Benutzerflows

Erstellen eines Asignio-Richtlinienschlüssels

Konfigurieren von Asignio als Identitätsanbieter

Hinzufügen von Asignio als Anspruchsanbieter

Hinzufügen einer User Journey

Hinzufügen des Identitätsanbieters zu einer User Journey

Konfigurieren einer Richtlinie für die vertrauende Seite

Hochladen der benutzerdefinierten Richtlinie

Testen der benutzerdefinierten Richtlinie

Nächste Schritte

Feedback

Zusätzliche Ressourcen