Esercitazione: Configurare IDEMIA Mobile ID con Azure Active Directory B2C

Articolo
01/26/2024

Prima di iniziare

Azure Active Directory B2C (Azure AD B2C) include due metodi per definire l'interazione degli utenti con applicazioni: flussi utente predefiniti o criteri personalizzati configurabili. Vedere La panoramica dei flussi utente e dei criteri personalizzati

Integrare Azure AD B2C con IDEMIA Mobile ID

IDEMIA offre servizi di autenticazione biometrica come l'ID viso e l'impronta digitale, che riduce il riutilizzo delle credenziali e delle frodi. Con L'ID mobile, i cittadini godono di un ID digitale attendibile e rilasciato dal governo, come complemento al proprio ID fisico. L'ID mobile verifica l'identità usando un PIN, un ID tocco o un ID viso auto-selezionato. I cittadini controllano le loro identità condividendo le informazioni necessarie per una transazione. Molti reparti di stato dei veicoli a motore (DMV) usano ID mobile.

Per altre informazioni, passare a idemia.com: IDEMIA

Descrizione dello scenario

L'integrazione di ID per dispositivi mobili include i componenti seguenti:

Azure AD B2C : server di autorizzazione che verifica le credenziali utente
- È noto anche come provider di identità (IdP)
IDEMIA Mobile ID - Provider OIDC (OpenID Connect) configurato come provider esterno di Azure AD B2C
- Vedere Aggiungere un provider di identità al tenant di Azure AD B2C
Applicazione IDEMIA Mobile ID : una versione digitale della licenza di un driver o un ID emesso dallo stato, in un'app sul telefono
- Vedere IDEMIA Mobile ID

L'ID mobile è un documento di identificazione digitalizzato, un token di identità mobile portatile usato dalle DMV per verificare le singole identità. L'ID digitalizzato firmato viene archiviato nei telefoni cellulari dell'utente come identità sul bordo. Le credenziali firmate semplificano l'accesso ai servizi di identità, ad esempio la prova di età, la conoscenza finanziaria del cliente, l'accesso all'account e così via.

Il diagramma seguente illustra i flussi utente di iscrizione e accesso con L'ID mobile.

Diagramma dei flussi utente di iscrizione e accesso con ID mobile.

L'utente visita la pagina di accesso di Azure AD B2C (la parte di risposta), con il dispositivo e l'ID mobile, per eseguire una transazione.
Azure AD B2C esegue un controllo ID. Reindirizza l'utente al router IDEMIA con un flusso di codice di autorizzazione OIDC.
Il router invia una sfida biometrica all'app per dispositivi mobili dell'utente con i dettagli della richiesta di autenticazione e autorizzazione.
A seconda della sicurezza, l'utente potrebbe essere richiesto di fornire altri dettagli: immettere un PIN, scattare un selfie live o entrambi.
La risposta di autenticazione fornisce la prova del possesso, della presenza e del consenso. La risposta restituisce al router.
Il router verifica le informazioni utente e le risposte ad Azure AD B2C con il risultato.
L'utente viene concesso o negato l'accesso.

Abilitare l'ID mobile

Per iniziare, passare alla pagina di contatto idemia.com Ottenere il tocco per richiedere una demo. Nel campo testo del modulo di richiesta indicare l'interesse per l'integrazione di Azure AD B2C.

Integrare l'ID mobile con Azure AD B2C

Usare le sezioni seguenti per preparare ed eseguire processi di integrazione.

Prerequisiti

Per iniziare, è necessario:

Accesso agli utenti con UN IDEMIA, stato USA emesso credenziali id mobile (mID)
- Oppure durante la fase di test, l'applicazione demo mID da IDEMIA
Una sottoscrizione di Azure
- Se non ne hai uno, ottieni un account gratuito di Azure
Un tenant di Azure AD B2C collegato alla sottoscrizione di Azure
Applicazione Web aziendale registrata in un tenant di Azure AD B2C
- Per i test, configurare https://jwt.ms, un'applicazione Web Microsoft con contenuto di token decodificato
Nota

Il contenuto del token non lascia il browser.

Inviare un'applicazione relying party per mID

Durante l'integrazione di ID mobile, vengono fornite le informazioni seguenti.

Proprietà	Descrizione
Nome dell'applicazione	Azure AD B2C o un altro nome dell'applicazione
Client_ID	Identificatore univoco dal provider di identità (IdP)
Client Secret	Password dell'applicazione relying party usata per l'autenticazione con IDEMIA IdP
Endpoint dei metadati	UN URL che punta a un documento di configurazione dell'autorità di certificazione del token, noto anche come endpoint di configurazione OpenID noto
URI di reindirizzamento	`https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/oauth2/authresp` Ad esempio: `https://fabrikam.b2clogin.com/fabrikam.onmicrosoft.com/oauth2/authresp` Se si usa un dominio personalizzato, immettere `https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp`.
URI di reindirizzamento post-disconnessione	`https://your-B2C-tenant-name.b2clogin.com/your-B2C-tenant-name.onmicrosoft.com/{policy}/oauth2/v2.0/logout` Inviare una richiesta di disconnessione.

Nota

È necessario l'ID client e il segreto client in un secondo momento per configurare l'IDP in Azure AD B2C.

Creare una chiave dei criteri

Archiviare il segreto client IDEMIA annotato nel tenant di Azure AD B2C. Per le istruzioni seguenti, usare la directory con il tenant di Azure AD B2C.

Accedere al portale di Azure.
Nella barra degli strumenti del portale selezionare Directory e sottoscrizioni.
Nella pagina Directory e sottoscrizioni delle impostazioni del portale individuare la directory B2C di Azure AD
Selezionare Commutatore.
Nell'angolo superiore sinistro di portale di Azure selezionare Tutti i servizi.
Cercare e selezionare Azure Active Directory B2C.
Nella pagina Panoramica selezionare Identity Experience Framework.
Selezionare Chiavi dei criteri.
Selezionare Aggiungi.
Per Opzioni scegliere Manuale.
Immettere un nome per la chiave dei criteri. Ad esempio: IdemiaAppSecret. Il prefisso B2C_1A_ viene aggiunto al nome della chiave.
In Segreto immettere il segreto client annotato.
Per Utilizzo delle chiavi selezionare Firma.
Selezionare Crea.

Configurare l'ID mobile come IDP esterno

Per consentire agli utenti di accedere con ID mobile, definire IDEMIA come provider di attestazioni. Questa azione garantisce che Azure AD B2C comunichi tramite un endpoint, che fornisce attestazioni usate da Azure AD B2C per verificare l'autenticazione utente con i dati di biometria.

Per definire IDEMIA come provider di attestazioni, aggiungerlo all'elemento ClaimsProvider nel file di estensione dei criteri.

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

Impostare client_id sull'ID applicazione ottenuto con la registrazione dell'applicazione.

Proprietà	Descrizione
Scope	Per OpenID Connect (OIDC), il requisito minimo è impostato su openid. Aggiungere più ambiti come elenco delimitato da spazio.
redirect_uri	Questa posizione è la posizione in cui l'agente utente invia il codice di autorizzazione ad Azure AD B2C.
response_type	Per il flusso del codice di autorizzazione, selezionare codice
acr_values	Questo parametro controlla i metodi di autenticazione che l'utente deve eseguire durante l'autenticazione.

Selezionare uno dei valori seguenti:

Valore del parametro	Effetto sul processo di autenticazione utente
`loa-2`	Solo autenticazione a più fattori basata su crittografia Microsoft Entra
`loa-3`	MFA basata su crittografia, oltre a un altro fattore
`loa-4`	Autenticazione a più fattori basata su crittografia, oltre all'utente che esegue l'autenticazione biometrica e il PIN

L'endpoint /userinfo fornisce le attestazioni per gli ambiti richiesti nella richiesta di autorizzazione. Per il <mt_scope> sono presenti attestazioni come nome, cognome e numero di licenza del conducente, tra gli altri elementi. Le attestazioni impostate per un ambito vengono pubblicate nella sezione scope_to_claims_mapping dell'API di individuazione. Azure AD B2C richiede attestazioni dall'endpoint delle attestazioni e le restituisce nell'elemento OutputClaims. Potrebbe essere necessario eseguire il mapping del nome dell'attestazione nel criterio al nome nel provider di identità. Definire il tipo di attestazione nell'elemento ClaimSchema:

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

Aggiungere un percorso utente

Per queste istruzioni, l'IdP è configurato, ma non si trova in alcuna pagina di accesso. Se non si ha un percorso utente personalizzato, copiare un percorso utente modello.

Dal pacchetto iniziale aprire il TrustFrameworkBase.xml file.
Individuare e copiare il contenuto dell'elemento UserJourneys , che include ID=SignUpOrSignIn.
Aprire il file TrustFrameworkExtensions.xml.
Individuare l'elemento UserJourneys . Se non è presente alcun elemento, aggiungerne uno.
Incollare il contenuto dell'elemento UserJourney come elemento figlio dell'elemento UserJourneys.
Rinominare l'ID percorso utente. Ad esempio, ID=CustomSignUpSignIn.

Aggiungere il provider di identità a un percorso utente

Se è presente un percorso utente, aggiungervi il nuovo IdP. Aggiungere prima un pulsante di accesso, quindi collegarlo a un'azione, ovvero il profilo tecnico creato.

Nel percorso utente individuare l'elemento del passaggio di orchestrazione con Type=CombinedSignInAndSignUpo Type=ClaimsProviderSelection. In genere è il primo passaggio di orchestrazione. L'elemento ClaimsProviderSelections ha un elenco IdP con cui gli utenti accedono. L'ordine dei controlli degli elementi è l'ordine dei pulsanti di accesso visualizzati dall'utente.
Aggiungere un elemento XML ClaimsProviderSelection .
Impostare il valore TargetClaimsExchangeId su un nome descrittivo.
Aggiungere un elemento ClaimsExchange .
Impostare l'ID sul valore dell'ID dello scambio di attestazioni di destinazione.
Aggiornare il valore TechnicalProfileReferenceId all'ID profilo tecnico creato.

Il codice XML seguente illustra i primi due passaggi di orchestrazione di un percorso utente con 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>

Configurare i criteri della relying party

I criteri della relying party, ad esempio SignUpSignIn.xml, specificano il percorso utente eseguito da Azure AD B2C.

Trovare l'elemento DefaultUserJourney nella relying party.
Aggiornare il ReferenceId in modo che corrisponda all'ID percorso utente in cui è stato aggiunto il provider di identità.

Nell'esempio seguente, per il CustomSignUpOrSignIn percorso utente, ReferenceId è impostato su CustomSignUpOrSignIn.

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

Caricare il criterio personalizzati

Per le istruzioni seguenti, usare la directory con il tenant di Azure AD B2C.

Accedere al portale di Azure.
Nella barra degli strumenti del portale selezionare Directory e sottoscrizioni.
Nella pagina Directory e sottoscrizioni delle impostazioni del portale individuare la directory di Azure AD B2C nell'elenco Nome directory .
Selezionare Cambia.
Nel portale di Azure cercare e selezionare Azure AD B2C.
In Criteri selezionare Identity Experience Framework.
Selezionare Carica criteri personalizzati.
Caricare i due file dei criteri modificati, nell'ordine seguente:
- Criteri di estensione, ad esempio TrustFrameworkExtensions.xml
- Criteri della relying party, ad esempio SignUpSignIn.xml

Testare i criteri personalizzati

Selezionare i criteri della relying party, ad esempio B2C_1A_signup_signin.
In Applicazione selezionare un'applicazione Web registrata.
https://jwt.msviene visualizzato per URL di risposta.
Selezionare Esegui adesso.
Nella pagina di iscrizione o accesso selezionare IDEMIA.
Il browser viene reindirizzato a https://jwt.ms. Vedere il contenuto del token restituito da Azure AD B2C.

Altre informazioni: Esercitazione: Registrare un'applicazione Web in Azure AD B2C

Condividi tramite