Configurare Asignio con Azure Active Directory B2C per l'autenticazione a più fattori

Informazioni su come integrare Microsoft Entra ID (Azure AD B2C) con Asignio. Con questa integrazione, offrire ai clienti un'esperienza di autenticazione senza password, biometrica temporanea e multifactoring. Asignio usa la firma Asignio patentata e la verifica facciale attiva per l'autenticazione utente. La firma biometrica modificabile consente di ridurre password, frodi, phishing e riutilizzo delle credenziali tramite l'autenticazione multicanale.

Prima di iniziare

Scegliere un selettore di tipi di criteri per indicare la configurazione del tipo di criterio. Azure AD B2C offre due metodi per definire il modo in cui gli utenti interagiscono con le applicazioni:

• Flussi utente predefiniti
• Criteri personalizzati configurabili

I passaggi descritti in questo articolo differiscono per ogni metodo.

Altre informazioni:

• Panoramica dei flussi utente e dei criteri personalizzati
• Panoramica dei criteri personalizzati di Azure AD B2C

Prerequisiti

• Una sottoscrizione di Azure.

• Se non è disponibile, ottenere un account gratuito di Azure

• Un tenant di Azure AD B2C collegato alla sottoscrizione di Azure

• Vedere Esercitazione: Creare un tenant B2C di Azure Active Directory

• ID client Asignio e segreto client rilasciato da Asignio.

• Questi token vengono ottenuti registrando le applicazioni Web o per dispositivi mobili con Asignio.

Per i criteri personalizzati

Esercitazione completa: Creare flussi utente e criteri personalizzati in Azure AD B2C

Descrizione dello scenario

Questa integrazione include i componenti seguenti:

• Azure AD B2C - server di autorizzazione che verifica le credenziali utente
• Applicazioni Web o per dispositivi mobili : per proteggere con Asignio MFA
• Applicazione Web Asignio - Raccolta biometrica di firme nel dispositivo tocco utente

Il diagramma seguente illustra l'implementazione.

1. L'utente apre la pagina di accesso di Azure AD B2C nella propria applicazione Mobile o Web e quindi accede o si registra.
2. Azure AD B2C reindirizza l'utente a Asignio usando una richiesta OIDC (OpenID Connect).
3. L'utente viene reindirizzato all'applicazione Web Asignio per l'accesso biometrico. Se l'utente non ha registrato la firma Asignio, può usare un SMS One-Time-Password (OTP) per l'autenticazione. Dopo l'autenticazione, l'utente riceve un collegamento di registrazione per creare la firma Asignio.
4. L'utente esegue l'autenticazione con Asignio Signature e verifica facciale o voce e verifica facciale.
5. La risposta alla sfida passa a Asignio.
6. Asignio restituisce la risposta OIDC all'accesso di Azure AD B2C.
7. Azure AD B2C invia una richiesta di verifica di autenticazione a Asignio per confermare la ricezione dei dati di autenticazione.
8. L'utente viene concesso o negato l'accesso all'applicazione.

Configurare un'applicazione con Asignio

La configurazione di un'applicazione con Asignio è con il sito di amministrazione del partner Asignio.

1. Passare a asignio.com pagina Amministrazione partner Asignio per richiedere l'accesso per l'organizzazione.
2. Con le credenziali accedere a Asignio Partner Administration.
3. Creare un record per l'applicazione Azure AD B2C usando il tenant di Azure AD B2C. Quando si usa Azure AD B2C con Asignio, Azure AD B2C gestisce applicazioni connesse. Le app Asignio rappresentano le app nella portale di Azure.
4. Nel sito Amministrazione partner Asignio generare un ID client e un segreto client.
5. Prendere nota e archiviare l'ID client e il segreto client. Verranno usati in un secondo momento. Asignio non archivia i segreti client.
6. Immettere l'URI di reindirizzamento nel sito a cui viene restituito l'utente dopo l'autenticazione. Usare il modello URI seguente.

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

7. Caricare un logo aziendale. Viene visualizzato nell'autenticazione di Asignio quando gli utenti accedono.

Registrare un'applicazione Web in Azure AD B2C

Registrare le applicazioni in un tenant gestito, quindi possono interagire con Azure AD B2C.

Altre informazioni: Tipi di applicazione che possono essere usati in Active Directory B2C

Per questa esercitazione si sta registrando https://jwt.ms, un'applicazione Web Microsoft con contenuti token decodificati che non lasciano il browser.

Registrare un'applicazione Web e abilitare la concessione implicita del token ID

Esercitazione completa: Registrare un'applicazione Web in Azure Active Directory B2C

Configurare Asignio come provider di identità in Azure AD B2C

Per le istruzioni seguenti, usare il tenant Microsoft Entra con la sottoscrizione di Azure.

1. Accedere alla portale di Azure come amministratore globale del tenant di Azure AD B2C.
2. Nella barra degli strumenti portale di Azure selezionare Directory e sottoscrizioni.
3. Nelle impostazioni del portale | Directory e sottoscrizioni, nell'elenco Nome directory individuare la directory Microsoft Entra.
4. Selezionare Commutatore.
5. Nell'angolo superiore sinistro della portale di Azure selezionare Tutti i servizi.
6. Cercare e selezionare Azure Active Directory B2C.
7. Nel portale di Azure cercare e selezionare Azure AD B2C.
8. Nel menu a sinistra selezionare Provider di identità.
9. Selezionare Nuovo provider OpenID Connect.
10. Selezionare Tipo di provider> di identitàOpenID Connect.
11. Per Nome immettere l'accesso Asignio o un nome scelto.
12. Per URL metadati immettere https://authorization.asignio.com/.well-known/openid-configuration.
13. Per ID client immettere l'ID client generato.
14. Per Segreto client immettere il segreto client generato.
15. Per Ambito, usare il profilo di posta elettronica openid.
16. Per Tipo di risposta, usare il codice.
17. Per la modalità Risposta, usare query.
18. Per Hint di dominio, usare https://asignio.com.
19. Selezionare OK.
20. Selezionare Mappare le attestazioni del provider di identità.
21. Per ID utente, usare sub.
22. Per Nome visualizzato, usare il nome.
23. Per Nome specificato, usare given_name.
24. Per Cognome, usare family_name.
25. Per Email, usare la posta elettronica.
26. Selezionare Salva.

SCreare un criterio di flusso utente

1. Nel tenant di Azure AD B2C, in Criteri selezionare Flussi utente.
2. Selezionare Nuovo flusso utente.
3. Selezionare Iscrizione e tipo di flusso utente di accesso.
4. Selezionare Versione consigliata.
5. Selezionare Crea.
6. Immettere un nome del flusso utente, ad esempio AsignioSignupSignin.
7. In Provider di identitàselezionare Nessuna per account locali. Questa azione disabilita l'autenticazione tramite posta elettronica e password.
8. Per Provider di identità personalizzati selezionare il provider di identità Asignio creato.
9. Selezionare Crea.

Testare il flusso utente

1. Nel tenant di Azure AD B2C selezionare Flussi utente.
2. Selezionare il flusso utente creato.
3. Per Applicazione selezionare l'applicazione Web registrata. L'URL di risposta è https://jwt.ms.
4. Selezionare Esegui il flusso utente.
5. Il browser viene reindirizzato alla pagina di accesso di Asignio.
6. Viene visualizzata una schermata di accesso.
7. Nella parte inferiore selezionare Autenticazione Asignio .

Se si dispone di una firma Asignio, completare la richiesta di autenticazione. In caso contrario, specificare il numero di telefono del dispositivo per l'autenticazione tramite SMS OTP. Usare il collegamento per registrare la firma di Asignio.

8. Il browser viene reindirizzato a https://jwt.ms. Vengono visualizzati i contenuti del token restituiti da Azure AD B2C.

Creare la chiave dei criteri Asignio

1. Archiviare il segreto client generato nel tenant di Azure AD B2C.
2. Accedere al portale di Azure.
3. Nella barra degli strumenti del portale selezionare le directory e le sottoscrizioni.
4. Nelle impostazioni del portale | Directory e sottoscrizioni, nell'elenco Dei nomi directory individuare la directory di Azure AD B2C.
5. Selezionare Commutatore.
6. Nell'angolo superiore sinistro della portale di Azure selezionare Tutti i servizi.
7. Cercare e selezionare Azure Active Directory B2C.
8. Nella pagina Panoramica selezionare Framework dell'esperienza di gestione delle identità.
9. Selezionare Chiavi dei criteri.
10. Selezionare Aggiungi.
11. Selezionare Manuale in Opzioni.
12. Immettere un nome della chiave di criterio per la chiave dei criteri. Il prefisso B2C_1A_ viene aggiunto al nome della chiave.
13. In Segreto immettere il segreto client annotato.
14. Per Uso chiave selezionare Firma.
15. Selezionare Create (Crea).

Configurare Asignio come provider di identità

Suggerimento

Prima di iniziare, assicurarsi che i criteri di Azure AD B2C siano configurati. In caso contrario, seguire le istruzioni nel pacchetto di avvio dei criteri personalizzati.

Per consentire agli utenti di accedere con Asignio, definire Asignio come provider di attestazioni con cui Azure AD B2C comunica tramite un endpoint. L'endpoint fornisce attestazioni che Azure AD B2C usa per verificare l'autenticazione utente con l'ID digitale nel dispositivo.

Aggiungere Asignio come provider di attestazioni

Ottenere i pacchetti di avvio dei criteri personalizzati da GitHub, quindi aggiornare i file XML nel starter pack LocalAccounts con il nome del tenant di Azure AD B2C:

1. Scaricare il file zip active-directory-b2c-custom-policy-starterpack o clonare il repository:

       git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
   

2. Nei file nella directory LocalAccounts sostituire la stringa yourtenant con il nome del tenant di Azure AD B2C.

3. Aprire LocalAccounts/TrustFrameworkExtensions.xml.

4. Trovare l'elemento ClaimsProviders. Se non ne esiste uno, aggiungerlo sotto l'elemento radice, TrustFrameworkPolicy.

5. Aggiungere un nuovo ClaimsProvider simile all'esempio seguente:

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

6. Impostare client_id con l'ID applicazione Asignio annotato.

7. Aggiornare client_secret sezione con la chiave dei criteri creata. Ad esempio, B2C_1A_AsignioSecret:

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

8. Salvare le modifiche.

Aggiungere un percorso utente

Il provider di identità non si trova nelle pagine di accesso.

1. Se si dispone di un percorso utente personalizzato, continuare a Configurare i criteri di relying party, in caso contrario, copiare un percorso utente modello:
2. Dal starter pack aprire LocalAccounts/TrustFrameworkBase.xml.
3. Individuare e copiare il contenuto dell'elemento UserJourney che includono Id=SignUpOrSignIn.
4. Aprire LocalAccounts/TrustFrameworkExtensions.xml.
5. Individuare l'elemento UserJourneys . Se non ne esiste uno, aggiungerne uno.
6. Incollare il contenuto dell'elemento UserJourney come elemento figlio dell'elemento UserJourneys.
7. Rinominare l'ID percorso utente. Ad esempio, Id=AsignioSUSI.

Altre informazioni: Percorsi utente

Aggiungere il provider di identità a un percorso utente

Aggiungere il nuovo provider di identità al percorso utente.

1. Trovare l'elemento passaggio di orchestrazione che include Type=CombinedSignInAndSignUp, o Type=ClaimsProviderSelection nel percorso utente. In genere è il primo passaggio di orchestrazione. L'elemento ClaimsProviderSelections include un elenco di provider di identità con cui gli utenti accedono. L'ordine degli elementi controlla l'ordine dei pulsanti di accesso.
2. Aggiungere un elemento XML ClaimsProviderSelection .
3. Impostare il valore di TargetClaimsExchangeId su un nome descrittivo.
4. Aggiungere un elemento ClaimsExchange .
5. Impostare l'ID sul valore dell'ID dell'ID di scambio delle attestazioni di destinazione.
6. Aggiornare il valore di TechnicalProfileReferenceId all'ID del profilo tecnico creato.

Il codice XML seguente illustra l'orchestrazione del percorso utente con il provider di identità.

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

Configurare i criteri di relying party

Il criterio di relying party, ad esempio SignUpSignIn.xml, specifica il percorso utente eseguito da Azure AD B2C.

1. Nella relying party individuare l'elemento DefaultUserJourney .
2. Aggiornare ReferenceId per corrispondere all'ID percorso utente in cui è stato aggiunto il provider di identità.

Nell'esempio seguente, per il AsignioSUSI percorso utente, il ReferenceId è impostato su AsignioSUSI:

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

Caricare il criterio personalizzati

1. Accedere al portale di Azure.
2. Nella barra degli strumenti del portale selezionare le directory e le sottoscrizioni.
3. Nelle impostazioni del portale | Directory e sottoscrizioni, nell'elenco Dei nomi directory individuare la directory di Azure AD B2C.
4. Selezionare Commutatore.
5. Nel portale di Azure cercare e selezionare Azure AD B2C.
6. In Criteri selezionare Identity Experience Framework.
7. Selezionare Carica criteri personalizzati.
8. Caricare i due file di criteri modificati nell'ordine seguente:

• Criteri di estensione, ad esempio TrustFrameworkExtensions.xml
• Criteri di relying party, ad esempio SignUpOrSignin.xml

Testare i criteri personalizzati

1. Nel tenant di Azure AD B2C e in Criteri selezionare Identity Experience Framework.
2. In Criteri personalizzati selezionare AsignioSUSI.
3. Per Applicazione selezionare l'applicazione Web registrata. L'URL di risposta è https://jwt.ms.
4. Selezionare Esegui adesso.
5. Il browser viene reindirizzato alla pagina di accesso di Asignio.
6. Viene visualizzata una schermata di accesso.
7. Nella parte inferiore selezionare Autenticazione Asignio .

Se si dispone di una firma Asignio, viene richiesto di eseguire l'autenticazione con la firma Asignio. In caso contrario, specificare il numero di telefono del dispositivo per l'autenticazione tramite SMS OTP. Usare il collegamento per registrare la firma di Asignio.

8. Il browser viene reindirizzato a https://jwt.ms. Vengono visualizzati i contenuti del token restituiti da Azure AD B2C.

Passaggi successivi

• Soluzioni e training per Azure Active Directory B2C
• Porre domande su Stackoverflow
• Esempi di Azure AD B2C
• YouTube: Identity Azure AD B2C Series
• Panoramica dei criteri personalizzati di Azure AD B2C
• Esercitazione: Creare flussi utente e criteri personalizzati in Azure Active Directory B2C