Lernprogramm: Konfigurieren von IDEMIA Mobile ID mit Azure Active Directory B2C

Bevor Sie anfangen

Azure Active Directory B2C (Azure AD B2C) verfügt über zwei Methoden zum Definieren der Benutzerinteraktion mit Anwendungen: vordefinierte Benutzerflüsse oder konfigurierbare benutzerdefinierte Richtlinien. Weitere Informationen finden Sie unter Übersicht über Benutzerflows und benutzerdefinierte Richtlinien.

Integrieren von Azure AD B2C mit IDEMIA Mobile ID

IDEMIA bietet biometrische Authentifizierungsdienste wie Gesichts-ID und Fingerabdruck, wodurch Betrug und Wiederverwendung von Anmeldeinformationen reduziert werden. Mit mobiler ID profitieren Bürger von einer vertrauenswürdigen, vom Staat ausgestellten digitalen ID als Ergänzung zu ihrer physischen ID. Mobile ID überprüft die Identität mithilfe einer selbst ausgewählten PIN, Touch-ID oder Gesichts-ID. Bürger kontrollieren ihre Identitäten, indem sie Informationen freigeben, die für eine Transaktion erforderlich sind. Viele staatliche Kfz-Zulassungsbehörden verwenden Mobile ID.

Weitere Informationen finden Sie unter idemia.com: IDEMIA

Szenariobeschreibung

Die Integration mobiler IDs umfasst die folgenden Komponenten:

• Azure AD B2C – Autorisierungsserver, der Benutzeranmeldeinformationen überprüft
  • Er wird auch als Identitätsanbieter (IdP) bezeichnet.
• IDEMIA Mobile ID – OpenID Connect (OIDC)-Anbieter, der als externer Azure AD B2C-Anbieter konfiguriert ist
  • Weitere Informationen finden Sie unter Hinzufügen eines Identitätsanbieters zu Ihrem Azure AD B2C-Mandanten.
• IDEMIA Mobile ID-Anwendung – eine digitale Version eines Führerscheins oder eine vom Staat ausgestellte ID in einer App auf Ihrem Smartphone
  • Siehe IDEMIA Mobile ID

Mobile ID ist ein digitalisiertes Identifikationsdokument, ein tragbares mobiles Identitätstoken, das DMVs zum Überprüfen einzelner Identitäten verwenden. Die signierte digitalisierte ID wird auf Benutzermobiltelefonen als Identität am Edge gespeichert. Die signierten Anmeldeinformationen erleichtern den Zugriff auf Identitätsdienste wie Altersnachweise, finanzielles Wissen Ihres Kunden, Kontozugriff usw.

Das folgende Diagramm veranschaulicht die Anmelde- und Anmeldebenutzerflüsse mit mobiler ID.

1. Der Benutzer besucht die Azure AD B2C-Anmeldeseite (die antwortende Partei) mit ihrem Gerät und der mobilen ID, um eine Transaktion durchzuführen.
2. Azure AD B2C führt eine ID-Überprüfung durch. Er leitet den Benutzer mit einem OIDC-Autorisierungscodefluss an den IDEMIA-Router weiter.
3. Der Router sendet eine biometrische Herausforderung an die mobile App des Benutzers mit Authentifizierungs- und Autorisierungsanforderungsdetails.
4. Je nach Sicherheit wird der Benutzer möglicherweise aufgefordert, weitere Details bereitzustellen: Eingabe einer PIN, Nehmen Sie ein Live-Selfie oder beides.
5. Die Authentifizierungsantwort stellt einen Nachweis des Besitzes, der Anwesenheit und der Zustimmung bereit. Die Antwort kehrt an den Router zurück.
6. Der Router überprüft Benutzerinformationen und antwortet Azure AD B2C mit dem Ergebnis.
7. Dem Benutzer wird der Zugriff gewährt oder verweigert.

Mobile ID aktivieren

Um zu beginnen, gehen Sie zur idemia.com Kontakt aufnehmen Seite, um eine Demo anzufordern. Geben Sie im Textfeld "Anforderungsformular" Ihr Interesse an der Azure AD B2C-Integration an.

Integrieren mobiler ID in Azure AD B2C

Verwenden Sie die folgenden Abschnitte, um sich auf Integrationsprozesse vorzubereiten und auszuführen.

Voraussetzungen

Um zu beginnen, benötigen Sie Folgendes:

• Zugriff für Nutzer, die eine von IDEMIA und einem US-Bundesstaat ausgestellte Mobile-ID besitzen (mID)

  • Oder während der Testphase die mID-Demoanwendung von IDEMIA

• Ein Azure-Abonnement

  • Wenn Sie kein Konto haben, erhalten Sie ein kostenloses Azure-Konto.

• Ein Azure AD B2C-Mandant, der mit dem Azure-Abonnement verknüpft ist

• Ihre Geschäftswebanwendung, die in einem Azure AD B2C-Mandanten registriert ist

  • Konfigurieren Sie https://jwt.mszum Testen eine Microsoft-Webanwendung mit decodierten Tokeninhalten.

  Hinweis

  Der Tokeninhalt verlässt den Browser nicht.

Übermitteln einer Anwendung der vertrauenden Seite für mID

Während der Integration mobiler ID werden die folgenden Informationen bereitgestellt.

Erstellen eines Richtlinienschlüssels

Speichern Sie den notierten IDEMIA-Clientschlüssel in Ihrem Azure AD B2C-Mandanten. Verwenden Sie für die folgenden Anweisungen das Verzeichnis mit Ihrem Azure AD B2C-Mandanten.

1. Melden Sie sich beim Azure-Portal an.
2. Wählen Sie auf der Portalsymbolleiste "Verzeichnisse + Abonnements" aus.
3. Suchen Sie auf der Seite "Portaleinstellungen" verzeichnisse + Abonnements in der Verzeichnisnamenliste Ihr Azure AD B2C-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. Wählen Sie auf der Seite "Übersicht " die Option "Identity Experience Framework" aus.
8. Wählen Sie "Richtlinienschlüssel" aus.
9. Wählen Sie Hinzufügen aus.
10. Wählen Sie unter "Optionen" die Option "Manuell" aus.
11. Geben Sie einen Namen für den Richtlinienschlüssel ein. Beispiel: IdemiaAppSecret. Das Präfix B2C_1A_ wird dem Schlüsselnamen hinzugefügt.
12. Geben Sie in Secret den geheimen Clientschlüssel ein, den Sie notiert haben.
13. Wählen Sie für die Schlüsselverwendung"Signatur" aus.
14. Wählen Sie "Erstellen" aus.

Konfigurieren von Mobile ID als externer Identitätsanbieter

Um Benutzern die Anmeldung mit mobiler ID zu ermöglichen, definieren Sie IDEMIA als Anspruchsanbieter. Diese Aktion stellt sicher, dass Azure AD B2C über einen Endpunkt kommuniziert, der Ansprüche bereitstellt, die Azure AD B2C verwendet, um die Benutzerauthentifizierung mit Biometrie zu überprüfen.

Um IDEMIA als Anspruchsanbieter zu definieren, fügen Sie es dem ClaimsProvider-Element in der Richtlinienerweiterungsdatei hinzu.

     <TechnicalProfile Id="Idemia-Oauth2">
          <DisplayName>IDEMIA</DisplayName>
          <Description>Login with your IDEMIA identity</Description>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="METADATA">https://idp.XXXX.net/oxauth/.well-known/openid-configuration</Item>
            <!-- Update the Client ID below to the Application ID -->
            <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
            <Item Key="response_types">code</Item>
            <Item Key="scope">openid id_basic mt_scope</Item>
            <Item Key="response_mode">form_post</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="UsePolicyInRedirectUri">false</Item>
            <Item Key="token_endpoint_auth_method">client_secret_basic</Item>
            <Item Key="ClaimsEndpoint">https://idp.XXXX.net/oxauth/restv1/userinfo</Item>
            <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_IdemiaAppSecret" />
</CryptographicKeys>
          <InputClaims>
            <InputClaim ClaimTypeReferenceId="acr" PartnerClaimType="acr_values" DefaultValue="loa-2" />
          </InputClaims>
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
            <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName1" />
            <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="lastName1" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="idemia" />
            <OutputClaim ClaimTypeReferenceId="documentId" />
            <OutputClaim ClaimTypeReferenceId="address1" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
           

Legen Sie „client_id“ auf die Anwendungs-ID aus der Anwendungsregistrierung fest.

Folgende Werte sind möglich:

Der /userinfo-Endpunkt stellt die Ansprüche für die in der Autorisierungsanforderung angeforderten Bereiche bereit. Für <mt_scope> gibt es unter anderem Ansprüche wie „Vorname“, „Nachname“ und „Führerscheinnummer“. Die für einen Bereich festgelegten Ansprüche werden im Abschnitt scope_to_claims_mapping der Ermittlungs-API veröffentlicht. Azure AD B2C fordert Ansprüche vom Anspruchsendpunkt an und gibt sie im OutputClaims-Element zurück. Möglicherweise müssen Sie den Anspruchsnamen in Ihrer Richtlinie dem Namen im IdP zuordnen. Definieren Sie den Anspruchstyp im ClaimSchema-Element:

<ClaimType Id="documentId">
     <DisplayName>documentId</DisplayName>
     <DataType>string</DataType>
</ClaimType>
<ClaimType Id="address1">
     <DisplayName>address</DisplayName>
     <DataType>string</DataType>
</ClaimType>

Hinzufügen einer Benutzerreise

Für diese Anleitungen wird der IdP eingerichtet, aber er befindet sich auf keiner Anmeldeseite. Wenn Sie keine benutzerdefinierte Benutzerreise haben, kopieren Sie eine Benutzerreise mit Vorlagen.

1. Öffnen Sie die TrustFrameworkBase.xml Datei aus dem Startpaket.
2. Suchen und kopieren Sie den Inhalt des UserJourneys Elements, das enthält ID=SignUpOrSignIn.
3. Öffnen Sie die Datei TrustFrameworkExtensions.xml.
4. Suchen Sie das UserJourneys-Element . Wenn kein Element vorhanden ist, fügen Sie ein Element hinzu.
5. Fügen Sie den Inhalt des UserJourney-Elements als untergeordnetes Element des UserJourneys-Elements ein.
6. Benennen Sie die Benutzerreise-ID um. Beispiel: ID=CustomSignUpSignIn.

Hinzufügen des Identitätsanbieters zu einer User Journey

Wenn es eine User Journey gibt, fügen Sie ihr den neuen Identitätsanbieter hinzu. Fügen Sie zuerst eine Anmeldeschaltfläche hinzu, und verknüpfen Sie sie dann mit einer Aktion, bei der es sich um das von Ihnen erstellte technische Profil handelt.

1. Suchen Sie in der User Journey nach dem Orchestrierungsschrittelement mit „Type=CombinedSignInAndSignUp“ oder „Type=ClaimsProviderSelection“. Es ist in der Regel der erste Orchestrierungsschritt. Das ClaimsProviderSelections-Element verfügt über eine IdP-Liste, mit der sich Benutzer anmelden. Die Reihenfolge der Bedienelemente bestimmt die Reihenfolge der Anmeldeschaltflächen, die der Benutzer sieht.
2. Fügen Sie ein ClaimsProviderSelection-XML-Element hinzu.
3. Legen Sie den Wert von TargetClaimsExchangeId auf einen freundlichen 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 TechnicalProfileReferenceId-Wert auf die von Ihnen erstellte technische Profil-ID.

Der folgende XML-Code veranschaulicht die ersten beiden Orchestrierungsschritte einer Benutzerreise mit dem IdP:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="IdemiaExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="IdemiaExchange" TechnicalProfileReferenceId="Idemia-Oauth2" />
  </ClaimsExchanges>
</OrchestrationStep>

Konfigurieren einer 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.

1. Suchen Sie unter „Vertrauende Seite“ das DefaultUserJourney-Element.
2. Aktualisieren Sie die ReferenceId so, dass sie der Benutzerreise-ID entspricht, in der Sie den IdP hinzugefügt haben.

Im folgenden Beispiel wird für den CustomSignUpOrSignIn Benutzerpfad die ReferenceId auf CustomSignUpOrSignIn festgelegt.

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

Hochladen der benutzerdefinierten Richtlinie

Verwenden Sie für die folgenden Anweisungen das Verzeichnis mit Ihrem Azure AD B2C-Mandanten.

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 Verzeichnisnamenliste 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 geänderten Richtliniendateien in der folgenden Reihenfolge hoch:

   • Die Erweiterungsrichtlinie (z. B. TrustFrameworkExtensions.xml)
   • Die Richtlinie für die vertrauende Seite, z. B. SignUpSignIn.xml

Testen der benutzerdefinierten Richtlinie

1. Wählen Sie die Richtliniendatei für die vertrauende Seite aus, z. B. B2C_1A_signup_signin.
2. Wählen Sie für "Anwendung" eine webanwendung aus, die Sie registriert haben.
3. https://jwt.mswird für antwort-URL angezeigt.
4. Wählen Sie Jetzt ausführen aus.
5. Wählen Sie auf der Registrierungs- oder Anmeldeseite IDEMIA aus.
6. Der Browser wird umgeleitet zu https://jwt.ms. Sehen Sie sich die tokeninhalte an, die von Azure AD B2C zurückgegeben werden.

Weitere Informationen: Lernprogramm: Registrieren einer Webanwendung in Azure AD B2C

Nächste Schritte

• Übersicht über benutzerdefinierte Azure AD B2C-Richtlinien
• Lernprogramm: Erstellen von Benutzerflüssen und benutzerdefinierten Richtlinien in Azure AD B2C
• Wechseln Sie zu idemia.com für mobile ID: Nachweisen Ihrer Identität mit größerem Datenschutz