Condividi tramite

Configurare la sicurezza della trasmissione con Azure Active Directory B2C per la prevenzione delle frodi

Importante

A partire dal 1° maggio 2025, Azure AD B2C non sarà più disponibile per l'acquisto per i nuovi clienti. Altre informazioni sono disponibili nelle domande frequenti.

In questa esercitazione viene illustrato come integrare l'autenticazione di Azure Active Directory B2C (Azure AD B2C) con i servizi di rilevamento e risposta (DRS) di Transmit Security. Transmit Security consente di rilevare i rischi nelle interazioni con i clienti sui canali digitali e di consentire decisioni informate sull'identità e sulla fiducia in tutta l'esperienza del consumatore.

Questa funzionalità è disponibile solo per i criteri personalizzati. Per i passaggi di installazione, selezionare Criteri personalizzati nel selettore precedente.

Descrizione dello scenario

Un'integrazione di Transmit Detection and Response include i seguenti componenti:

  • Tenant di Azure AD B2C: ospita uno script che raccoglie informazioni sul dispositivo mentre gli utenti eseguono un criterio mirato e autentica l'utente. Blocca o contesta i tentativi di accesso/aggiornamento in base alla raccomandazione di rischio restituita da Transmit.
  • Modelli di interfaccia utente personalizzati: personalizza il contenuto HTML delle pagine di cui viene eseguito il rendering da Azure AD B2C. Queste pagine includono gli snippet JavaScript necessari per il rilevamento dei rischi di trasmissione.
  • Trasmissione del servizio di raccolta dati: script incorporato dinamicamente che registra le informazioni sul dispositivo, che viene utilizzato per valutare continuamente il rischio durante le interazioni dell'utente.
  • Endpoint API DRS: fornisce la raccomandazione sui rischi basata sui dati raccolti. Azure AD B2C comunica con questo endpoint usando un connettore API REST.
  • Funzioni di Azure: l'endpoint API ospitato usato per ottenere una raccomandazione dall'endpoint API Transmit DRS tramite il connettore API.

Il diagramma dell'architettura seguente illustra l'implementazione descritta nella guida:

Diagramma dell'architettura Transmit e Azure AD B2C.

  1. L'utente accede con Azure AD B2C.
  2. Una pagina personalizzata inizializza l'SDK di trasmissione, che avvia lo streaming delle informazioni sul dispositivo a Transmit.
  3. Azure AD B2C segnala un evento di azione di accesso a Transmit per ottenere un token di azione.
  4. La trasmissione restituisce un token di azione e Azure AD B2C procede con l'iscrizione o l'accesso dell'utente.
  5. Dopo l'accesso dell'utente, Azure AD B2C richiede una raccomandazione sui rischi da Transmit tramite la funzione di Azure.
  6. La funzione di Azure invia la richiesta di raccomandazione con il token di azione.
  7. Trasmetti restituisce una raccomandazione (sfida/consenti/nega) in base alle informazioni raccolte sul dispositivo.
  8. La funzione di Azure passa il risultato della raccomandazione ad Azure AD B2C per gestirlo di conseguenza.
  9. Azure AD B2C esegue altri passaggi, se necessario, ad esempio l'autenticazione a più fattori e completa il flusso di iscrizione o accesso.

Prerequisiti

Passaggio 1: crea un'app di trasmissione

Accedere al portale di amministrazione di Transmit e creare un'applicazione:

  1. Da Applicazioni, seleziona Aggiungi applicazione.

  2. Configurare l'applicazione con i seguenti attributi:

    Proprietà Descrizione
    Nome applicazione Nome applicazione
    Nome del cliente Nome del client
    URI di reindirizzamento Inserisci l'URL del tuo sito web. Questo attributo è un campo obbligatorio ma non viene utilizzato per questo flusso

  3. Seleziona Aggiungi.

  4. Al momento della registrazione, vengono visualizzati un ID client e un segreto client . Registrare i valori per utilizzarli in seguito.

Passaggio 2: crea l'interfaccia utente personalizzata

Inizia integrando Transmit DRS nell'applicazione frontend B2C. Creare una pagina di accesso personalizzata che integri l'SDK di trasmissione e sostituisca la pagina di accesso predefinita di Azure AD B2C.

Una volta attivato, Transmit DRS inizia a raccogliere informazioni per l'utente che interagisce con l'app. Transmit DRS restituisce un token di azione necessario per Azure AD B2C per la raccomandazione del rischio.

Per integrare Transmit DRS nella pagina di accesso B2C, attenersi alla seguente procedura:

  1. Prepara un file HTML personalizzato per la tua pagina di accesso in base ai modelli di esempio. Aggiungere lo script seguente per caricare e inizializzare l'SDK di trasmissione e per ottenere un token di azione. Il token di azione restituito deve essere archiviato in un elemento HTML nascosto (ts-drs-response in questo esempio).

    <!-- Function that obtains an action token -->
<script>
function fill_token() {
   window.tsPlatform.drs.triggerActionEvent("login").then((actionResponse) => {
      let actionToken = actionResponse.actionToken;
      document.getElementById("ts-drs-response").value = actionToken;
      console.log(actionToken);
   });
}
</script>

<!-- Loads DRS SDK -->
<script src="https://platform-websdk.transmitsecurity.io/platform-websdk/latest/ts-platform-websdk.js" defer> </script>

<!-- Upon page load, initializes DRS SDK and calls the fill_token function -->
<script defer>
window.onload = function() {
   if (window.tsPlatform) {
      // Client ID found in the app settings in Transmit Admin portal
      window.tsPlatform.initialize({ clientId: "[clientId]" });
      console.log("Transmit Security platform initialized");
      fill_token();
   } else {/
      console.error("Transmit Security platform failed to load");
   }
};
</script>

  2. Abilitare le versioni JavaScript e del layout di pagina in Azure AS B2C.

  3. Ospitare la pagina HTML in un endpoint Web abilitato per la condivisione di risorse tra le origini (CORS) creando un account di archiviazione e aggiungendo il supporto CORS per Archiviazione di Azure.

Passaggio 3: Creare una funzione di Azure

Azure AD B2C può ottenere una raccomandazione sui rischi da Transmit utilizzando un connettore API. Il passaggio di questa richiesta tramite un'API Web intermedia (ad esempio l'uso di Funzioni di Azure) offre una maggiore flessibilità nella logica di implementazione.

Seguire questa procedura per creare una funzione di Azure che usa il token di azione dall'applicazione front-end per ottenere una raccomandazione dall'endpoint Transmit DRS.

  1. Creare il punto di ingresso della funzione di Azure, una funzione attivata da HTTP che elabora le richieste HTTP in ingresso.

    public static async Task<HttpResponseMessage> Run(HttpRequest req, ILogger log)
{
    // Function code goes here
}

  2. Estrarre il token di azione dalla richiesta. I criteri personalizzati definiscono come passare la richiesta, nei parametri della stringa di query o nel corpo.

    // Checks for the action token in the query string
string actionToken = req.Query["actiontoken"];

// Checks for the action token in the request body
string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
dynamic data = JsonConvert.DeserializeObject(requestBody);
actionToken = actionToken ?? data?.actiontoken;

  3. Convalidare il token dell'azione verificando che il valore fornito non sia vuoto o null:

    // Returns an error response if the action token is missing
if (string.IsNullOrEmpty(actionToken))
   {
       var respContent = new { version = "1.0.0", status = (int)HttpStatusCode.BadRequest, userMessage = "Invalid or missing action token" };
       var json = JsonConvert.SerializeObject(respContent);
       log.LogInformation(json);
       return new HttpResponseMessage(HttpStatusCode.BadRequest)
       {
           Content = new StringContent(json, Encoding.UTF8, "application/json")
       };
   }

  4. Invocare l'API Transmit DRS. L'ID client di trasmissione e il segreto client ottenuti nel passaggio 1 devono essere utilizzati per generare token di connessione per l'autorizzazione API. Assicurati di aggiungere le variabili di ambiente necessarie (come ClientId e ClientSecret) nel tuo local.settings.json file.

    HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Add("Authorization", $"Bearer {transmitSecurityApiKey}");

// Add code here that sends this GET request:
// https://api.transmitsecurity.io/risk/v1/recommendation?action_token=[YOUR_ACTION_TOKEN]

HttpResponseMessage response = await client.GetAsync(urlWithActionToken);

  5. Elabora la risposta API. Il codice seguente inoltra la risposta API in caso di esito positivo; in caso contrario, gestisce eventuali errori.

     if (response.IsSuccessStatusCode)
   {
       log.LogInformation(responseContent);
       return new HttpResponseMessage(HttpStatusCode.OK)
       {
           Content = new StringContent(responseContent, Encoding.UTF8, "application/json")
       };
   }
   else
   {
       var errorContent = new { version = "1.0.0", status = (int)response.StatusCode, userMessage = "Error calling Transmit Security API" };
       var json = JsonConvert.SerializeObject(errorContent);
       log.LogError(json);
       return new HttpResponseMessage(response.StatusCode)
       {
           Content = new StringContent(json, Encoding.UTF8, "application/json")
       };
   }

Passaggio 4: Configurare i criteri personalizzati

È possibile incorporare Transmit DRS nell'applicazione Azure B2C estendendo i criteri personalizzati.

  1. Per iniziare, scaricare lo starter pack per i criteri personalizzati (vedere Creare criteri personalizzati in Azure AD B2C)

  2. Creare un nuovo file che eredita da TrustFrameworkExtensions, che estende la policy di base con personalizzazioni specifiche del tenant per Transmit DRS.

    <BasePolicy>
   <TenantId>YOUR AZURE TENANT</TenantId>
   <PolicyId>B2C_1A_TrustFrameworkExtensions</PolicyId>
</BasePolicy>

  3. BuildingBlocks Nella sezione, definire actiontoken, ts-drs-response, e ts-drs-recommendation come attestazioni:

    <BuildingBlocks>
   <ClaimsSchema>
   <ClaimType Id="ts-drs-response">
      <DisplayName>ts-drs-response</DisplayName>
      <DataType>string</DataType>
      <UserHelpText>Parameter provided to the DRS service for the response</UserHelpText>
      <UserInputType>TextBox</UserInputType>
   </ClaimType>
   <ClaimType Id="actiontoken">
      <DisplayName>actiontoken</DisplayName>
      <DataType>string</DataType>
      <UserHelpText />
      <UserInputType>TextBox</UserInputType>
   </ClaimType>
   <ClaimType Id="ts-drs-recommendation">
      <DisplayName>recommendation</DisplayName>
      <DataType>string</DataType>
      <UserHelpText />
      <UserInputType>TextBox</UserInputType>
   </ClaimType>
   </ClaimsSchema>
<BuildingBlocks>

  4. Nella sezione aggiungere un riferimento all'interfaccia BuildingBlocks utente personalizzata:

    <BuildingBlocks>
   <ClaimsSchema>
   <!-- your claim schemas-->
   </ClaimsSchema>

   <ContentDefinitions>
   <ContentDefinition Id="api.selfasserted">
   <!-- URL of your hosted custom HTML file-->
      <LoadUri>YOUR_SIGNIN_PAGE_URL</LoadUri>
   </ContentDefinition>
   </ContentDefinitions>
</BuildingBlocks>

  5. Configurare un provider di attestazioni nella sezione ClaimsProviders che includa i seguenti profili tecnici: uno (SelfAsserted-LocalAccountSignin-Email) che emette il token di azione, e un altro (login-DRSCheck nell'esempio) relativo alla funzione di Azure che riceve il token di azione come input e fornisce la raccomandazione di rischio.

    <ClaimsProviders>
   <ClaimsProvider>
   <DisplayName>Sign in using DRS</DisplayName>
   <TechnicalProfiles>
      <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
         <DisplayName>Local Account Sign-in</DisplayName>
         <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
         <Metadata>
         <Item Key="SignUpTarget">SignUpWithLogonEmailExchange</Item>
         <Item Key="setting.operatingMode">Email</Item>
         <Item Key="setting.showSignupLink">true</Item>
         <Item Key="setting.showCancelButton">false</Item>
         <Item Key="ContentDefinitionReferenceId">api.selfasserted</Item>
         <Item Key="language.button_continue">Sign In</Item>
         </Metadata>
         <IncludeInSso>false</IncludeInSso>
         <InputClaims>
         <InputClaim ClaimTypeReferenceId="signInName" />
         </InputClaims>
         <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="signInName" Required="true" />
         <OutputClaim ClaimTypeReferenceId="password" Required="true" />
         <OutputClaim ClaimTypeReferenceId="objectId" />
         <OutputClaim ClaimTypeReferenceId="authenticationSource" />
         <!-- Outputs the action token value provided by the frontend-->
         <OutputClaim ClaimTypeReferenceId="ts-drs-response" />
         </OutputClaims>
         <ValidationTechnicalProfiles>
         <ValidationTechnicalProfile ReferenceId="login-DRSCheck" />
         <ValidationTechnicalProfile ReferenceId="login-NonInteractive" />
         </ValidationTechnicalProfiles>
      </TechnicalProfile>
      <TechnicalProfile Id="login-DRSCheck">
         <DisplayName>DRS check to validate the interaction and device </DisplayName>
         <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
         <Metadata>
         <!-- Azure Function App -->
         <Item Key="ServiceUrl">YOUR_FUNCTION_URL</Item>
         <Item Key="AuthenticationType">None</Item>
         <Item Key="SendClaimsIn">Body</Item>
         <!-- JSON, Form, Header, and Query String formats supported -->
         <Item Key="ClaimsFormat">Body</Item>
         <!-- Defines format to expect claims returning to B2C -->
         <!-- REMOVE the following line in production environments -->
         <Item Key="AllowInsecureAuthInProduction">true</Item>
         </Metadata>
         <InputClaims>
         <!-- Receives the action token value as input -->
         <InputClaim ClaimTypeReferenceId="ts-drs-response" PartnerClaimType="actiontoken" DefaultValue="0" />
         </InputClaims>
         <OutputClaims>
         <!-- Outputs the risk recommendation value returned by Transmit (via the Azure function) -->
         <OutputClaim ClaimTypeReferenceId="ts-drs-recommendation" PartnerClaimType="recommendation.type" />
         </OutputClaims>
      </TechnicalProfile>
   </TechnicalProfiles>
   </ClaimsProvider>
</ClaimsProviders>

  6. Nella sezione UserJourneys, crea un nuovo percorso utente (SignInDRS nell'esempio) che identifichi l'utente ed esegua i passaggi appropriati per la protezione dell'identità in base alla raccomandazione sul rischio di Transmit. Ad esempio, il viaggio può procedere normalmente se Transmit restituisce consente o ritiene attendibile, termina e informa l'utente del problema se 'rifiuta', oppure si dovrebbe attivare un processo di autenticazione avanzata se challenge.

  <UserJourneys>
    <UserJourney Id="SignInDRS">
      <OrchestrationSteps>
        <!-- Step that identifies the user by email and stores the action token -->
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.selfasserted">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- Step to perform DRS check -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <ClaimsExchanges>
            <ClaimsExchange Id="DRSCheckExchange" TechnicalProfileReferenceId="login-DRSCheck" />
          </ClaimsExchanges>
        </OrchestrationStep>

        <!-- Conditional step for ACCEPT or TRUST -->
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
              <Value>ts-drs-recommendation</Value>
              <Value>ACCEPT</Value>
              <Value>TRUST</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <!-- Define the ClaimsExchange or other actions for ACCEPT or TRUST -->
        </OrchestrationStep>

        <!-- Conditional step for CHALLENGE -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
              <Value>ts-drs-recommendation</Value>
              <Value>CHALLENGE</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <!-- Define the ClaimsExchange or other actions for CHALLENGE -->
        </OrchestrationStep>

        <!-- Conditional step for DENY -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
              <Value>ts-drs-recommendation</Value>
              <Value>DENY</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <!-- Define the ClaimsExchange or other actions for DENY -->
        </OrchestrationStep>
    </UserJourney>
  </UserJourneys>

  1. Salvare il file dei criteri come DRSTrustFrameworkExtensions.xmlfile.

  2. Creare un nuovo file che erediti dal file salvato. Estende i criteri di autenticazione che fungono da punto di ingresso per i percorsi utente di registrazione e autenticazione con Transmit DRS.

    <BasePolicy>
   <TenantId>YOUR AZURE TENANT</TenantId>
   <PolicyId>B2C_1A_DRSTrustFrameworkExtensions</PolicyId>
</BasePolicy>

  3. RelyingParty Nella sezione, configura il percorso utente ottimizzato per DRS (SignInDRS nel nostro esempio).

    <RelyingParty>
   <DefaultUserJourney ReferenceId="SignInDRS" />
   <UserJourneyBehaviors>
   <ScriptExecution>Allow</ScriptExecution>
   </UserJourneyBehaviors>
   <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" />
   </OutputClaims>
   <SubjectNamingInfo ClaimType="sub" />
   </TechnicalProfile>
</RelyingParty>

  4. Salvare il file dei criteri come DRSSignIn.xmlfile.

Passaggio 5: Caricare i criteri personalizzati

Usa la directory del tuo tenant di Azure AD B2C e carica le politiche personalizzate.

  1. Accedi al portale di Azure.
  2. Nella barra degli strumenti del portale selezionare Directory e sottoscrizioni.
  3. Nella pagina Impostazioni del portale | Directory + sottoscrizioni, trovare nell'elenco Nome directory la directory di Azure AD B2C e quindi selezionare Passa.
  4. Sotto Politiche, selezionare Identity Experience Framework.
  5. Selezionare Carica criteri personalizzati e quindi caricare i file dei criteri personalizzati aggiornati.

Passaggio 6: Testare i criteri personalizzati

Utilizzando la directory del tenant di Azure AD B2C, testare la policy personalizzata:

  1. Nel tenant di Azure AD B2C, sotto la sezione "Criteri", seleziona Identity Experience Framework.
  2. In Criteri personalizzati selezionare il criterio di accesso.
  3. Per Applicazione, selezionare l'applicazione Web registrata.
  4. Selezionare Esegui adesso.
  5. Completa il flusso utente.

Passaggi successivi