Freigeben über

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

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.

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.

Bevor Sie anfangen

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

Für benutzerdefinierte Richtlinien

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

Szenariobeschreibung

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.

  1. Der Benutzer öffnet die Azure AD B2C-Anmeldeseite in der mobilen oder Webanwendung und meldet sich dann an oder registriert sich.
  2. Azure AD B2C leitet den Benutzer mithilfe einer OIDC-Anforderung (OpenID Connect) an Asignio um.
  3. 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 SMS One-Time-Password (OTP) zur Authentifizierung verwenden. Nach der Authentifizierung erhält der Benutzer einen Registrierungslink, um seine Asignio-Signatur zu erstellen.
  4. Der Benutzer authentifiziert sich mit seiner Asignio-Signatur und Gesichtsüberprüfung oder einer Sprach- und Gesichtsüberprüfung.
  5. Die Abfrageantwort geht an Asignio.
  6. Asignio gibt die OIDC-Antwort an die Azure AD B2C-Anmeldung zurück.
  7. Azure AD B2C sendet eine Authentifizierungsüberprüfungsanforderung an Asignio, um den Empfang der Authentifizierungsdaten zu bestätigen.
  8. Dem Benutzer wird der Zugriff auf die Anwendung gewährt oder verweigert.

Konfigurieren einer Anwendung mit Asignio

Die Konfiguration einer Anwendung erfolgt über die Asignio Partner-Administrationsseite.

  1. Um Zugriff für Ihre Organisation anzufordern, wechseln Sie zu asignio.com SeiteAsignio-Partnerverwaltung.
  2. Melden Sie sich mit Anmeldeinformationen bei Asignio Partner Administration an.
  3. 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.
  4. Generieren Sie auf der Asignio Partner Administration-Website eine Client-ID und einen geheimen Clientschlüssel.
  5. Notieren und speichern Sie die Client-ID und den geheimen Clientschlüssel. Sie werden sie später noch benötigen. Geheime Clientschlüssel werden nicht von Asignio gespeichert.
  6. 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].

  1. Laden Sie ein Firmenlogo 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, und sie können mit Azure AD B2C interagieren.

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

Für dieses Tutorial registrieren Sie https://jwt.ms, eine Microsoft-Webanwendung mit decodierten Tokeninhalten, die Ihren Browser nicht verlassen.

Registrieren einer Webanwendung

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

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.

  1. Melden Sie sich im Azure-Portal mindestens in der Rolle eines B2C IEF-Richtlinienadministrators des Azure AD B2C-Mandanten an.
  2. Wählen Sie auf der Symbolleiste des Azure-Portals Verzeichnisse + Abonnements aus.
  3. Suchen Sie auf der Seite Portaleinstellungen | Verzeichnisse + Abonnements in der Liste Verzeichnisname Ihr Microsoft Entra-Verzeichnis.
  4. Wählen Sie Wechseln aus.
  5. Wählen Sie in der oberen linken Ecke des Azure-Portals "Alle Dienste" aus.
  6. Suchen Sie nach Azure AD B2C, und wählen Sie diese Option aus.
  7. Suchen Sie im Azure-Portal nach Azure AD B2C, und wählen Sie diese Option dann aus.
  8. Wählen Sie im linken Bereich Identitätsanbieter aus.
  9. Wählen Sie "Neuer OpenID Connect-Anbieter" aus.
  10. Wählen Sie den Identitätsanbietertyp>OpenID Connect aus.
  11. Geben Sie unter Name die Asignio-Anmeldung oder einen gewünschten Namen ein.
  12. Geben Sie für https://authorization.asignio.com/.well-known/openid-configuration ein.
  13. Geben Sie unter Client-ID die von Ihnen generierte Client-ID ein.
  14. Geben Sie unter Geheimer Clientschlüssel den von Ihnen generierten geheimen Clientschlüssel ein.
  15. Verwenden Sie für Bereich das OpenID-E-Mail-Profil.
  16. Verwenden Sie Code für den Antworttyp.
  17. Verwenden Sie als Antwortmodus die Option Abfrage.
  18. Verwenden Sie für Domänenhinweise die Option https://asignio.com.
  19. Wählen Sie OK aus.
  20. Wählen Sie Ansprüche dieses Identitätsanbieters zuordnen aus.
  21. Verwenden Sie für Benutzer-ID die Option sub.
  22. Verwenden Sie für Anzeigename die Option Name.
  23. Verwenden Sie für Vorname den Wert given_name.
  24. Verwenden Sie für Nachnamefamily_name.
  25. Verwenden Sie für E-Mail die Option Email.
  26. Wählen Sie Speichern aus.

Erstellen einer Benutzerflussrichtlinie

  1. Wählen Sie in Ihrem Azure AD B2C-Mandanten unter "Richtlinien" die Option "Benutzerflüsse" aus.
  2. Wählen Sie "Neuer Benutzerablauf" aus.
  3. Wählen Sie den Benutzerflowtyp Registrierung und Anmeldung aus.
  4. Wählen Sie Empfohlene Version aus.
  5. Wählen Sie "Erstellen" aus.
  6. Geben Sie einen Namen für den Benutzerflow ein, z. B. AsignioSignupSignin.
  7. Wählen Sie unter Identitätsanbieter für Lokale Konten die Option Keine aus. Diese Aktion deaktiviert die E-Mail- und Kennwortauthentifizierung.
  8. Wählen Sie unter Benutzerdefinierte Identitätsanbieter den erstellten Asignio-Identitätsanbieter aus.
  9. Wählen Sie "Erstellen" aus.

Testen des Benutzerablaufs

  1. Wählen Sie in Ihrem Azure AD B2C-Mandanten Benutzerflüsse aus.
  2. Wählen Sie den erstellten Benutzerflow aus.
  3. Wählen Sie für "Anwendung" die webanwendung aus, die Sie registriert haben. Die Antwort-URL lautet https://jwt.ms.
  4. Wählen Sie Benutzerflow ausführen aus.
  5. Der Browser wird an die Anmeldeseite von Asignio umgeleitet.
  6. Ein Anmeldebildschirm wird angezeigt.
  7. 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.

  1. Der Browser wird umgeleitet zu https://jwt.ms. Der von Azure AD B2C zurückgegebene Tokeninhalt wird angezeigt.

Erstellen eines Asignio-Richtlinienschlüssels

  1. Speichern Sie den generierten geheimen Clientschlüssel im Azure AD B2C-Mandanten.
  2. Melden Sie sich beim Azure-Portal an.
  3. Wählen Sie auf der Portalsymbolleiste die Verzeichnisse + Abonnements aus.
  4. Suchen Sie auf der Seite Portaleinstellungen | Verzeichnisse + Abonnements in der Liste Verzeichnisname Ihr Azure AD B2C-Verzeichnis.
  5. Wählen Sie Wechseln aus.
  6. Wählen Sie in der oberen linken Ecke des Azure-Portals "Alle Dienste" aus.
  7. Suchen Sie nach Azure AD B2C, und wählen Sie diese Option aus.
  8. Wählen Sie auf der Seite "Übersicht" die Option "Identity Experience Framework" aus.
  9. Wählen Sie "Richtlinienschlüssel" aus.
  10. Wählen Sie Hinzufügen aus.
  11. Wählen Sie unter "Optionen" die Option "Manuell" aus.
  12. Geben Sie einen Richtlinienschlüsselnamen für den Richtlinienschlüssel ein. Das Präfix B2C_1A_ wird an den Schlüsselnamen angefügt.
  13. Geben Sie unter Geheimnis den geheimen Clientschlüssel ein, den Sie sich notiert haben.
  14. Wählen Sie für die Schlüsselverwendung"Signatur" aus.
  15. Wählen Sie "Erstellen" aus.

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

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 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

  2. Ersetzen Sie in den Dateien im Verzeichnis "LocalAccounts " die Zeichenfolge yourtenant durch den Azure AD B2C-Mandantennamen.

  3. Öffnen Sie die Datei LocalAccounts/ TrustFrameworkExtensions.xml.

  4. Suchen Sie das ClaimsProviders-Element . Wenn keine vorhanden ist, fügen Sie sie unter dem Stammelement „TrustFrameworkPolicy“ hinzu.

  5. Fügen Sie einen neuen ClaimsProvider ähnlich dem 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">00001111-aaaa-2222-bbbb-3333cccc4444</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="aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"></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/00001111-aaaa-2222-bbbb-3333cccc4444</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>

  6. Legen Sie client_id auf die Asignio-Anwendungs-ID, die Sie sich notiert haben, fest.

  7. Aktualisieren Sie den Abschnitt client_secret mit dem Richtlinienschlüssel, den Sie erstellt haben. Beispiel: B2C_1A_AsignioSecret:

    <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />

  8. Speichern Sie die Änderungen.

Hinzufügen einer Benutzerreise

Der Identitätsanbieter befindet sich nicht auf den Anmeldeseiten.

  1. 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:
  2. Öffnen Sie im Starter-Paket die Datei LocalAccounts/ TrustFrameworkBase.xml.
  3. Suchen und kopieren Sie den Inhalt des UserJourney-Elements, das Id=SignUpOrSignIn enthält.
  4. Öffnen Sie die Datei LocalAccounts/ TrustFrameworkExtensions.xml.
  5. Suchen Sie das UserJourneys-Element . Wenn keins vorhanden ist, fügen Sie eins hinzu.
  6. Fügen Sie die Inhalte des UserJourney-Elements als untergeordnetes Element des UserJourneys-Elements ein.]
  7. Benennen Sie die ID der User Journey um. Beispiel: Id=AsignioSUSI.

Weitere Informationen: User Journeys

Fügen Sie den Identitätsanbieter zu einem Benutzerablauf hinzu

Fügen Sie den neuen Identitätsanbieter zum Benutzerfluss hinzu.

  1. 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 verfügt über eine Identitätsanbieterliste, mit der sich Benutzer anmelden. Die Reihenfolge der Elemente steuert die Reihenfolge der Anmeldeschaltflächen.
  2. Fügen Sie ein ClaimsProviderSelection-XML-Element hinzu.
  3. Legen Sie den Wert von TargetClaimsExchangeId auf einen benutzerfreundlichen Namen fest.
  4. Fügen Sie ein ClaimsExchange-Element hinzu.
  5. Legen Sie die ID auf den Wert der Zielanspruchsaustausch-ID fest.
  6. Aktualisieren Sie den Wert von TechnicalProfileReferenceId auf die ID des von Ihnen erstellten technischen Profils.

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 der vertrauenden Seite, z. B. SignUpSignIn.xml, gibt die User Journey an, die Azure AD B2C ausführt.

  1. Suchen Sie in der vertrauenden Seite das DefaultUserJourney-Element.
  2. 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 AsignioSUSI Benutzerablauf die ReferenceId 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

  1. Melden Sie sich beim Azure-Portal an.
  2. Wählen Sie auf der Portalsymbolleiste die Verzeichnisse + Abonnements aus.
  3. Suchen Sie auf der Seite Portaleinstellungen | Verzeichnisse + Abonnements in der Liste Verzeichnisname Ihr Azure AD B2C-Verzeichnis.
  4. Wählen Sie Wechseln aus.
  5. Suchen Sie im Azure-Portal nach Azure AD B2C, und wählen Sie diese Option dann aus.
  6. Wählen Sie unter "Richtlinien " die Option "Identity Experience Framework" aus.
  7. Wählen Sie "Benutzerdefinierte Richtlinie hochladen" aus.
  8. Laden Sie die beiden Richtliniendateien hoch, die Sie in der folgenden Reihenfolge geändert haben:
  • Erweiterungsrichtlinie, z. B. TrustFrameworkExtensions.xml
  • Richtlinie für die vertrauende Seite z. B. SignUpOrSignin.xml

Teste deine benutzerdefinierte Richtlinie

  1. Wählen Sie in Ihrem Azure AD B2C-Mandanten unter "Richtlinien" die Option "Identity Experience Framework" aus.
  2. Wählen Sie unter Benutzerdefinierte Richtlinien die Richtlinie AsignioSUSI aus.
  3. Wählen Sie für "Anwendung" die Webanwendung aus, die Sie registriert haben. Die Antwort-URL lautet https://jwt.ms.
  4. Wählen Sie Jetzt ausführen aus.
  5. Der Browser wird an die Anmeldeseite von Asignio umgeleitet.
  6. Ein Anmeldebildschirm wird angezeigt.
  7. 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.

  1. Der Browser wird umgeleitet zu https://jwt.ms. Der von Azure AD B2C zurückgegebene Tokeninhalt wird angezeigt.

Nächste Schritte

  • Last updated on