Configurar a Segurança de Transmissão com o Azure Ative Directory B2C para Prevenção de Fraudes

Importante

A partir de 1º de maio de 2025, o Azure AD B2C não estará mais disponível para compra para novos clientes. Saiba mais nas nossas Perguntas Frequentes.

Neste tutorial, aprenda a integrar a autenticação do Azure Ative Directory B2C (Azure AD B2C) com os Serviços de Deteção e Resposta (DRS) do Transmit Security. O Transmit Security permite detetar riscos nas interações do cliente em canais digitais e permitir decisões informadas de identidade e confiança em toda a experiência do consumidor.

Este recurso está disponível apenas para políticas personalizadas. Para as etapas de configuração, selecione Política personalizada no seletor anterior.

Descrição do cenário

Uma integração de Deteção e Resposta de Transmissão inclui os seguintes componentes:

  • Locatário do Azure AD B2C: autentica o utilizador e aloja um script que coleta informações do dispositivo à medida que os utilizadores executam uma política alvo. Bloqueia ou questiona as tentativas de início de sessão/criação de conta baseada na recomendação de risco devolvida pelo Transmit.
  • Modelos de interface do usuário personalizados: personaliza o conteúdo HTML das páginas renderizadas pelo Azure AD B2C. Essas páginas incluem os trechos de JavaScript necessários para a deteção de risco de transmissão.
  • Serviço de coleta de dados de transmissão: script incorporado dinamicamente que registra informações do dispositivo, que é usado para avaliar continuamente o risco durante as interações do usuário.
  • Transmitir ponto de extremidade da API DRS: Fornece a recomendação de risco com base nos dados coletados. O Azure AD B2C comunica-se com este ponto de extremidade usando um conector de API REST.
  • Azure Functions: seu ponto de extremidade de API hospedado que é usado para obter uma recomendação do ponto de extremidade da API Transmit DRS por meio do conector de API.

O diagrama de arquitetura a seguir ilustra a implementação descrita no guia:

Diagrama da arquitetura Transmit e Azure AD B2C.

  1. O utilizador inicia sessão com o Azure AD B2C.
  2. Uma página personalizada inicializa o SDK de transmissão, que inicia o streaming de informações do dispositivo para o Transmit.
  3. O Azure AD B2C relata um evento de ação de início de sessão para o Transmit, a fim de obter um token de ação.
  4. Transmit fornece um token de ação e o Azure AD B2C prossegue com o registo ou início de sessão do utilizador.
  5. Depois que o utilizador entrar, o Azure AD B2C solicita uma recomendação de risco à Transmit por meio da Azure Function.
  6. A Função do Azure envia o pedido de recomendação com o token de ação.
  7. Transmitir retorna uma recomendação (desafiar/permitir/negar) com base nas informações coletadas do dispositivo.
  8. A Função Azure passa o resultado da recomendação para o Azure AD B2C para tratá-lo adequadamente.
  9. O Azure AD B2C executa mais etapas, se necessário, como a autenticação multifator, e conclui o fluxo de inscrição ou entrada.

Pré-requisitos

Etapa 1: Criar um aplicativo Transmit

Entre no Portal de Administração do Transmit e crie um aplicativo:

  1. Em Aplicativos, selecione Adicionar aplicativo.

  2. Configure o aplicativo com os seguintes atributos:

    Propriedade Descrição
    Nome do aplicativo Nome do aplicativo
    Nome do cliente Nome do cliente
    Redirecionar URIs Insira o URL do seu site. Este atributo é um campo obrigatório, mas não é usado para este fluxo

  3. Selecione Adicionar.

  4. Após o registo, é apresentado um ID do Cliente e um Segredo do Cliente . Registre os valores para uso posterior.

Etapa 2: criar sua interface do usuário personalizada

Comece integrando o Transmit DRS ao aplicativo frontend B2C. Crie uma página de entrada personalizada que integre o SDK de transmissão e substitua a página de entrada padrão do Azure AD B2C.

Uma vez ativado, o Transmit DRS começa a coletar informações para o usuário que interage com seu aplicativo. Transmitir DRS retorna um token de ação que o Azure AD B2C precisa para recomendação de risco.

Para integrar o Transmit DRS na página de início de sessão B2C, siga estas etapas:

  1. Prepare um arquivo HTML personalizado para sua página de entrada com base nos modelos de exemplo. Adicione o script a seguir para carregar e inicializar o SDK de transmissão e obter um token de ação. O token de ação retornado deve ser armazenado em um elemento HTML oculto (ts-drs-response neste exemplo).

    <!-- 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. Habilite JavaScript e versões de layout de página no Azure AS B2C.

  3. Hospede a página HTML em um ponto de extremidade da Web habilitado para CORS (Compartilhamento de Recursos entre Origens) criando uma conta de armazenamento e adicionando suporte a CORS para o Armazenamento do Azure.

Etapa 3: Criar uma função do Azure

O Azure AD B2C pode obter uma recomendação de risco do Transmit usando um conector de API. Passar essa solicitação por meio de uma API Web intermediária (como usar o Azure Functions) fornece mais flexibilidade em sua lógica de implementação.

Siga estas etapas para criar uma função do Azure que usa o token de ação da aplicação frontend para obter uma recomendação do endpoint Transmit DRS.

  1. Crie o ponto de entrada da sua Função do Azure, uma função acionada por HTTP que processa solicitações HTTP de entrada.

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

  2. Extraia o token de ação da solicitação. A sua política personalizada define como enviar a solicitação, nos parâmetros de query string ou no 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. Valide o token de ação verificando se o valor fornecido não está vazio ou nulo:

    // 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. Chame a API Transmit DRS. O ID do Cliente de Transmissão e o Segredo do Cliente obtidos na Etapa 1 devem ser usados para gerar tokens de portador para autorização de API. Certifique-se de adicionar as variáveis de ambiente necessárias (como ClientId e ClientSecret) em seu local.settings.json arquivo.

    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. Processe a resposta da API. O código a seguir encaminha a resposta da API se for bem-sucedida; caso contrário, lida com quaisquer erros.

     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")
       };
   }

Etapa 4: Configurar suas políticas personalizadas

Você incorpora o Transmit DRS em seu aplicativo Azure B2C estendendo suas políticas personalizadas.

  1. Baixe o pacote inicial de políticas personalizadas para começar (consulte Criar políticas personalizadas no Azure AD B2C)

  2. Crie um novo ficheiro que herde de TrustFrameworkExtensions, o qual estende a política base com personalizações específicas do tenant para Transmit DRS.

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

  3. BuildingBlocks Na seção, defina actiontoken, ts-drs-responsee ts-drs-recommendation como reivindicações:

    <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. BuildingBlocks Na seção , adicione uma referência à sua interface do usuário personalizada:

    <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. Na seção ClaimsProviders, configure um provedor de declarações que inclua os seguintes perfis técnicos: um (SelfAsserted-LocalAccountSignin-Email) que emite o token de ação, e outro (login-DRSCheck em nosso exemplo) para a função do Azure que recebe o token de ação como entrada e emite a recomendação de risco.

    <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. Na seção UserJourneys, crie uma nova jornada do utilizador (SignInDRS no nosso exemplo) que identifique o utilizador e execute as etapas apropriadas de proteção de identidade com base na recomendação de risco do Transmit. Por exemplo, a viagem pode prosseguir normalmente se a Transmissão retornar permitir ou confiar, caso negue, encerrar e informar o utilizador sobre o problema, ou acionar um processo de autenticação de nível superior se desafiar.

  <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. Salve o arquivo de política como DRSTrustFrameworkExtensions.xml.

  2. Crie um novo arquivo que herda do arquivo que você salvou. Ele estende a política de entrada que funciona como um ponto de entrada para as jornadas do usuário de inscrição e login com o Transmit DRS.

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

  3. RelyingParty Na seção , configure sua jornada de usuário aprimorada pelo DRS (SignInDRSno nosso exemplo).

    <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. Salve o arquivo de política como DRSSignIn.xml.

Etapa 5: carregar a política personalizada

Usando o diretório com o seu inquilino do Azure AD B2C, carregue a política personalizada:

  1. Inicie sessão no portal Azure.
  2. Na barra de ferramentas do portal, selecione Diretórios + assinaturas.
  3. Nas configurações do Portal | Página Diretórios + assinaturas , na lista Nome do diretório , localize o diretório do Azure AD B2C e selecione Alternar.
  4. Em Políticas, selecione Identity Experience Framework.
  5. Selecione Carregar política personalizada e, em seguida, carregue os arquivos de política personalizada atualizados.

Etapa 6: Testar sua política personalizada

Usando o diretório com a sua instância do Azure AD B2C, teste a sua política personalizada:

  1. No locatário do Azure AD B2C e em Políticas, selecione Identity Experience Framework.
  2. Em Políticas personalizadas, selecione a Política de login.
  3. Em Aplicativo, selecione o aplicativo Web que você registrou.
  4. Selecione Executar agora.
  5. Conclua o fluxo do usuário.

Próximos passos

  • Last updated on