Självstudie: Konfigurera mobil-ID för IDEMIA med Azure Active Directory B2C

Innan du börjar

Azure Active Directory B2C (Azure AD B2C) har två metoder för att definiera användarnas interaktion med program: fördefinierade användarflöden eller konfigurerbara anpassade principer. Se Översikt över användarflöden och anpassade principer

Integrera Azure AD B2C med IDEMIA Mobile ID

IDEMIA tillhandahåller biometriska autentiseringstjänster som ansikts-ID och fingeravtryck, vilket minskar återanvändning av bedrägerier och autentiseringsuppgifter. Med mobil-ID drar medborgarna nytta av ett betrott, myndighetsbaserat digitalt ID som ett komplement till deras fysiska ID. Mobil-ID verifierar identiteten med hjälp av en självvald PIN-kod, touch-ID eller ansikts-ID. Medborgarna kontrollerar sina identiteter genom att dela information som behövs för en transaktion. Många statliga avdelningar för motorfordon (DMV: er) använder mobil-ID.

Mer information finns i idemia.com: IDEMIA

Scenariobeskrivning

Integreringen av mobil-ID omfattar följande komponenter:

• Azure AD B2C – auktoriseringsserver som verifierar användarautentiseringsuppgifter
  • Det kallas även identitetsprovidern (IdP)
• IDEMIA Mobile ID – OpenID Connect-provider (OIDC) konfigurerad som en Azure AD extern B2C-provider
  • Se Lägga till en identitetsprovider i din Azure AD B2C-klientorganisation
• IDEMIA Mobile ID-program – en digital version av ett körkort eller tillstånds utfärdat ID i en app på telefonen
  • Se IDEMIA Mobile ID

Mobil-ID är ett digitaliserat identifieringsdokument, en bärbar mobil identitetstoken som DMV:er använder för att verifiera enskilda identiteter. Det signerade digitaliserade ID:t lagras på användarens mobiltelefoner som en identitet på gränsenheten. De signerade autentiseringsuppgifterna underlättar åtkomsten till identitetstjänster, till exempel åldersbevis, kontoåtkomst och så vidare.

Följande diagram illustrerar användarflödena för registrering och inloggning med mobil-ID.

1. Användaren besöker Azure AD B2C-inloggningssida (svarsparten), med sin enhet och mobil-ID, för att genomföra en transaktion.
2. Azure AD B2C utför en ID-kontroll. Den omdirigerar användaren till IDEMIA-routern med ett OIDC-auktoriseringskodflöde.
3. Routern skickar en biometrisk utmaning till användarens mobilapp med information om autentisering och auktoriseringsbegäran.
4. Beroende på säkerhet kan användaren uppmanas att ange mer information: ange en PIN-kod, ta en live-selfie eller både och.
5. Autentiseringssvaret ger bevis på innehav, närvaro och medgivande. Svaret återgår till routern.
6. Routern verifierar användarinformation och svarar på Azure AD B2C med resultatet.
7. Användaren beviljas eller nekas åtkomst.

Aktivera mobil-ID

Kom igång genom att gå till sidan idemia.com Kom i kontakt för att begära en demo. I textfältet för begärandeformulär anger du ditt intresse för Azure AD B2C-integrering.

Integrera mobilt ID med Azure AD B2C

Använd följande avsnitt för att förbereda för och utföra integreringsprocesser.

Förutsättningar

Du behöver följande för att komma igång:

• Åtkomst till användare med en IDEMIA, usa-tillstånd utfärdad Mobile ID-autentiseringsuppgift (mID)

  • Eller under testfasen, mID-demoprogrammet från IDEMIA

• En Azure-prenumeration

  • Om du inte har ett konto kan du skaffa ett kostnadsfritt Azure-konto

• En Azure AD B2C-klientorganisation som är länkad till Azure-prenumerationen

• Ditt företagswebbprogram registrerat i en Azure AD B2C-klientorganisation

  • För testning konfigurerar https://jwt.msdu , ett Microsoft-webbprogram med avkodat tokeninnehåll

  Anteckning

  Tokeninnehållet lämnar inte webbläsaren.

Skicka ett förlitande part-program för mID

Under integreringen av mobil-ID tillhandahålls följande information.

Egenskap	Beskrivning
Programnamn	Azure AD B2C eller ett annat programnamn
Client_ID	Den unika identifieraren från identitetsprovidern (IdP)
Client Secret (Klienthemlighet)	Lösenord som programmet för förlitande part använder för att autentisera med IDEMIA IdP
Metadataslutpunkt	En URL som pekar på ett konfigurationsdokument för token utfärdare, även kallat en välkänd OpenID-konfigurationsslutpunkt
Omdirigerings-URI:er	https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp Till exempel https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp Om du använder en anpassad domän anger du https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp.
Omdirigerings-URI:er efter utloggning	https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/{policy}/oauth2/v2.0/logout Skicka en utloggningsbegäran.

Anteckning

Du behöver klient-ID och klienthemlighet senare för att konfigurera IdP i Azure AD B2C.

Skapa en principnyckel

Lagra den antecknade IDEMIA-klienthemligheten i din Azure AD B2C-klientorganisation. Följ anvisningarna nedan genom att använda katalogen med din Azure AD B2C-klientorganisation.

1. Logga in på Azure-portalen.
2. I portalverktygsfältet väljer du Kataloger + prenumerationer.
3. På sidan Kataloger + prenumerationer på portalinställningarna letar du upp din Azure AD B2C-katalog i listan Katalognamn
4. Välj Växla.
5. I det övre vänstra hörnet av Azure Portal väljer du Alla tjänster.
6. Sök efter och välj Azure AD B2C.
7. På sidan Översikt väljer du Identity Experience Framework.
8. Välj Principnycklar.
9. Välj Lägg till.
10. För Alternativ väljer du Manuell.
11. Ange ett namn för principnyckeln. Till exempel IdemiaAppSecret. Prefixet B2C_1A_ läggs till i nyckelnamnet.
12. I Hemlighet anger du den klienthemlighet som du antecknade.
13. För Nyckelanvändning väljer du Signatur.
14. Välj Skapa.

Konfigurera mobil-ID som en extern IdP

Om du vill göra det möjligt för användare att logga in med mobilt ID definierar du IDEMIA som anspråksprovider. Den här åtgärden säkerställer Azure AD B2C kommunicerar via en slutpunkt, vilket ger anspråk Azure AD B2C använder för att verifiera användarautentisering med biometri.

Om du vill definiera IDEMIA som en anspråksprovider lägger du till den i elementet ClaimsProvider i principtilläggsfilen.

     <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">00000000-0000-0000-0000-000000000000</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>
           

Ange client_id till program-ID från programregistreringen.

Egenskap	Beskrivning
Omfång	För OpenID Connect (OIDC) anges omfångsparametern till openid. Lägg till fler omfång som en blankstegsavgränsad lista.
redirect_uri	På den här platsen skickar användaragenten auktoriseringskoden till Azure AD B2C.
response_type	För auktoriseringskodflödet väljer du kod
acr_values	Den här parametern styr de autentiseringsmetoder som användaren måste utföra under autentiseringen.

Välj något av följande värden:

Parametervärde	Effekt på användarautentiseringsprocessen
loa-2	Endast kryptobaserad Microsoft Entra multifaktorautentisering
loa-3	Kryptobaserad MFA, plus en annan faktor
loa-4	Kryptobaserad MFA, plus att användaren utför PIN-kod och biometrisk autentisering

Slutpunkten /userinfo tillhandahåller anspråk för de omfång som begärdes i auktoriseringsbegäran. För mt_scope<> finns det anspråk som förnamn, efternamn och körkortsnummer, bland andra objekt. Anspråksuppsättningen för ett omfång publiceras i avsnittet scope_to_claims_mapping i identifierings-API:et. Azure AD B2C begär anspråk från anspråksslutpunkten och returnerar dem i elementet OutputClaims. Du kan behöva mappa anspråksnamnet i principen till namnet i IdP:t. Definiera anspråkstypen i elementet ClaimSchema:

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

Lägga till en användarresa

För dessa instruktioner är IdP konfigurerat, men det finns inte på någon inloggningssida. Om du inte har en anpassad användarresa kopierar du en mallanvändares resa.

1. Öppna filen från startpaketet TrustFrameworkBase.xml .
2. Leta upp och kopiera innehållet i elementet UserJourneys , som innehåller ID=SignUpOrSignIn.
3. Öppna TrustFrameworkExtensions.xml.
4. Leta upp elementet UserJourneys . Om det inte finns något element lägger du till ett.
5. Klistra in innehållet i elementet UserJourney som underordnad elementet UserJourneys.
6. Byt namn på användarens rese-ID. Till exempel ID=CustomSignUpSignIn.

Lägga till IdP i en användarresa

Om det finns en användarresa lägger du till den nya IdP:n i den. Lägg först till en inloggningsknapp och länka den sedan till en åtgärd, som är den tekniska profil som du skapade.

1. Under användarresan letar du upp orkestreringsstegelementet med Type=CombinedSignInAndSignUp, eller Type=ClaimsProviderSelection. Det är vanligtvis det första orkestreringssteget. Elementet ClaimsProviderSelections har en IdP-lista som användare loggar in med. Ordningen på elementkontrollerna är ordningen på de inloggningsknappar som användaren ser.
2. Lägg till xml-elementet ClaimsProviderSelection .
3. Ange värdet TargetClaimsExchangeId till ett eget namn.
4. Lägg till elementet ClaimsExchange .
5. Ange ID :t till värdet för målanspråkets utbytes-ID.
6. Uppdatera värdet TechnicalProfileReferenceId till det tekniska profil-ID som du skapade.

Följande XML visar de två första orkestreringsstegen för en användarresa med 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>

Konfigurera principen för förlitande part

Principen för förlitande part, till exempel SignUpSignIn.xml, anger användarens resa Azure AD B2C körs.

1. Hitta elementet DefaultUserJourney i förlitande part.
2. Uppdatera ReferenceId så att det matchar användarens rese-ID, där du lade till IdP:t.

I följande exempel för CustomSignUpOrSignIn användarresan är ReferenceId inställt på CustomSignUpOrSignIn.

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

Ladda upp den anpassade principen

Följ anvisningarna nedan genom att använda katalogen med din Azure AD B2C-klientorganisation.

1. Logga in på Azure-portalen.

2. I portalens verktygsfält väljer du Kataloger + prenumerationer.

3. På sidan Portalinställningar, Kataloger + prenumerationer letar du upp din Azure AD B2C-katalog i listan Katalognamn.

4. Välj Växla.

5. I Azure Portal söker du efter och väljer Azure AD B2C.

6. Under Principer väljer du Identity Experience Framework.

7. Välj Överför anpassad princip.

8. Ladda upp de två principfilerna som du ändrade i följande ordning:

   • Tilläggsprincipen, till exempel TrustFrameworkExtensions.xml
   • Den förlitande partens princip, till exempel SignUpSignIn.xml

Testa din anpassade princip

1. Välj din princip för förlitande part, till exempel B2C_1A_signup_signin.
2. För Program väljer du ett webbprogram som du har registrerat.
3. https://jwt.msvisas för svars-URL.
4. Välj Kör nu.
5. På registrerings- eller inloggningssidan väljer du IDEMIA.
6. Webbläsaren omdirigeras till https://jwt.ms. Se det tokeninnehåll som returneras av Azure AD B2C.

Läs mer: Självstudie: Registrera ett webbprogram i Azure AD B2C

Nästa steg

• översikt över Azure AD anpassad B2C-princip
• Självstudie: Skapa användarflöden och anpassade principer i Azure AD B2C
• Gå till idemia.com för mobil-ID: Bevisa din identitet med större sekretess