Compartilhar via

Configurar a Trusona Authentication Cloud com o Azure Active Directory B2C

  • Artigo

Neste tutorial de amostra, aprenda a como integrar a autenticação do Azure AD B2C com a Nuvem de Autenticação Trusona. É um serviço baseado em nuvem que permite que os usuários se autentiquem com uma experiência "tap-and-go", sem a necessidade de nenhum tipo de aplicativo autenticador móvel.

Os benefícios da integração da Trusona Authentication Cloud ao Azure AD B2C englobam:

  • Fornecer autenticação forte com uma melhor experiência para o usuário

    • Usuários mais felizes que gastam mais online
    • Menor atrito e abandono, aumento das receitas
    • Maior retenção, valor de tempo de vida (LTV)

  • Menor custo de funcionamento da empresa

    • Redução da invasão de contas e compartilhamento de contas
    • Redução de fraudes e menos ações manuais de análise de fraudes
    • Redução dos gastos com a terceirização de revisões manuais

  • As senhas são eliminadas

    • Sem redefinições de senha
    • Redução das reclamações no call center
    • Logins rápidos, simples e sem atrito usando chaves de acesso

Pré-requisitos

Para começar, você precisa do seguinte:

Descrição do cenário

Padrão de Autenticação da Web – o WebAuthn implementa sistemas operacionais e navegadores modernos para oferecer suporte à autenticação por meio de impressão digital, Windows Hello ou dispositivos FIDO externos, como USB, Bluetooth e OTP.

Nesse cenário, a Trusona atua como um Provedor de Identidade (IdP) do Azure AD B2C para habilitar a autenticação sem senha. Os componentes a seguir constituem a solução:

  • Uma política de entrada e inscrição combinadas do Azure AD B2C.
  • Trusona Authentication Cloud adicionada ao Azure AD B2C como um IdP.

Screenshot shows Trusona architecture diagram.

Etapas Descrição
1. Um usuário tenta entrar no aplicativo web através do navegador.
2. O aplicativo Web redireciona para a política de inscrição e entrada do Azure AD B2C.
3. O Azure AD B2C redireciona o usuário para autenticação no IdP do OIDC (OpenID Connect) da Trusona Authentication Cloud.
4. O usuário recebe uma página da web de entrada que solicita seu nome de usuário (geralmente um endereço de email).
5. O usuário insere seu endereço de email e seleciona o botão Continuar. Se a conta do usuário não for encontrada na Trusona Authentication Cloud, uma resposta é enviada ao navegador que inicia um processo de registro WebAuthn no dispositivo. Caso contrário, uma resposta é enviada para o navegador que inicia um processo de autenticação WebAuthn.
6. O usuário é solicitado a selecionar uma credencial a ser usada. A chave de acesso está associada ao domínio do aplicativo web ou a uma chave de segurança do hardware. Depois que o usuário seleciona uma credencial, o sistema operacional solicita que o usuário use uma biometria, senha ou PIN para confirmar sua identidade. Isso desbloqueia o ambiente de Execução Confiável/Enclave Seguro, que gera uma declaração de autenticação assinada pela chave privada associada à credencial selecionada.
7. A declaração de autenticação é retornada ao serviço de nuvem da Trusona para verificação.
8. Depois de verificada, a Trusona Authentication Cloud (IdP) cria um token de ID do OIDC e o encaminha para o Azure AD B2C (Provedor de Serviços). O Azure AD B2C valida a assinatura do token e do emissor em relação aos valores no documento de descoberta OpenID da Trusona. Esses detalhes foram configurados durante a instalação do IdP. Depois de verificado, o Azure AD B2C emite um id_token OIDC (dependendo do escopo) e redireciona o usuário de volta para o aplicativo iniciador com o token.
9. O aplicativo web (ou as bibliotecas de desenvolvedor que ele usa para implementar a autenticação) recupera o token e verifica a autenticidade do token do Azure AD B2C. Se esse for o caso, ele extrai as declarações e as passa para o aplicativo web para consumir.
10. Após a verificação, o acesso do usuário é concedido/negado.

Etapa 1: Integração com a Trusona Authentication Cloud

  1. Entre no Portal da Trusona.

  2. No painel de navegação esquerdo, selecione Configurações

  3. No menu Configurações, selecione o controle deslizante para Habilitar OIDC.

  4. Selecione as Entradas apropriadas e forneça a URL de Redirecionamentohttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp.

  5. Gere uma chave secreta e copie a chave para usar na configuração do Azure AD B2C.

    Observação

    1. O portal da Trusona oferece suporte ao registro de autoatendimento. Ao se registrar, você será atribuído a uma conta da Trusona com direitos de somente leitura. Posteriormente, a Trusona atribuirá você à conta correta e elevará seus direitos para leitura/gravação com base na política de controle de acesso da sua organização para os usuários do portal.
    2. O nome de domínio inicial da ID do Microsoft Entra é usado como o host de redirecionamento de cliente.

    Screenshot shows Trusona Authentication Cloud portal settings.

Etapa 2: registrar um aplicativo Web no Azure AD B2C

Antes que os aplicativos possam interagir com o Azure AD B2C, eles deverão ser registrados no locatário do cliente. Este tutorial mostra como registrar um Aplicativo Web usando o portal do Azure. Para fins de teste, como este tutorial, você está registrando https://jwt.ms, um aplicativo Web de propriedade da Microsoft que exibe o conteúdo decodificado de um token (o conteúdo do token nunca deixa o navegador). Para registrar um aplicativo web no seu locatário do Azure AD B2C, use nossa nova experiência de registro de aplicativo unificado.

  1. Entre no portal do Azure.

  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o locatário do Azure AD B2C no menu Diretórios + assinaturas.

  3. No portal do Azure, pesquise e selecione Azure AD B2C.

  4. Escolha Registros de aplicativo e Novo registro.

  5. Insira um Nome para o aplicativo. Por exemplo, jwt ms.

  6. Em Tipos de conta com suporte, selecione Contas em qualquer provedor de identidade ou diretório organizacional (para autenticar usuários com fluxos dos usuários) .

  7. Em URI de Redirecionamento, selecione Web e, em seguida, insira https://jwt.ms na caixa de texto da URL.

    O URI de redirecionamento é o ponto de extremidade para o qual o servidor de autorização (nesse caso, o Azure AD B2C) envia o usuário. Depois de concluir a interação com o usuário, um token de acesso ou código de autorização é enviado após a autorização bem-sucedida. Em um aplicativo de produção, normalmente é um ponto de extremidade de acesso público no qual o aplicativo está em execução, como https://contoso.com/auth-response. Para fins de teste, como este tutorial, você pode defini-lo como https://jwt.ms, um aplicativo da Web de propriedade da Microsoft que exibe o conteúdo decodificado de um token (o conteúdo do token nunca deixa o navegador). Durante o desenvolvimento do aplicativo, é possível adicionar o ponto de extremidade onde o aplicativo escuta localmente, como https://localhost:5000. Adicione e modifique URIs de redirecionamento nos aplicativos registrados a qualquer momento.

    As restrições a seguir se aplicam a URLs de redirecionamento:

    • A URL de resposta deve começar com o esquema https, a menos que você use uma URL de redirecionamento de localhost.
    • A URL de resposta diferencia maiúsculas de minúsculas. As letras maiúsculas e minúsculas devem corresponder às letras maiúsculas e minúsculas do caminho da URL do aplicativo em execução. Por exemplo, se o aplicativo incluir .../abc/response-oidc como parte de seu caminho, não especifique .../ABC/response-oidc na URL de resposta. Como o navegador da Web trata os caminhos diferenciando maiúsculas de minúsculas, os cookies associados a .../abc/response-oidc podem ser excluídos se forem redirecionados para a URL de .../ABC/response-oidc com maiúsculas e minúsculas não correspondentes.
    • A URL de resposta deve incluir ou excluir a barra à direita conforme o aplicativo espera. Por exemplo, https://contoso.com/auth-response e https://contoso.com/auth-response/ podem ser tratados como URLs incompatíveis em seu aplicativo.

  8. Em Permissões, marque a caixa de seleção Dar consentimento do administrador às permissões OpenID e offline_access.

  9. Selecione Registrar.

Habilitar concessão implícita de token de ID

Se você registrar este aplicativo e configurá-lo com o aplicativo https://jwt.ms/ para testar um fluxo de usuário ou uma política personalizada, será necessário habilitar o fluxo de concessão implícito no registro do aplicativo:

  1. No menu à esquerda, em Gerenciar, selecione Autenticação.

  2. Na seção Concessão implícita e fluxos híbridos, selecione as caixas de seleção Tokens de ID (usados para fluxos implícitos e híbridos).

  3. Clique em Salvar.

Etapa 3: Configurar a Trusona Authentication Cloud como um IdP no Azure AD B2C

  1. Entre no portal do Azure como administrador global do locatário Azure AD B2C.

  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o locatário do Azure AD B2C no menu Diretórios + assinaturas.

  3. Escolha Todos os serviços no canto superior esquerdo do portal do Azure, procure e selecione Azure AD B2C.

  4. Navegue até os Painel>Azure Active Directory B2C>Provedores de identidade.

  5. Selecione Provedores de identidade.

  6. Selecione Adicionar.

Configurar um IdP

  1. Selecione o Tipo de provedor de identidade>OpenID Connect (versão prévia) .

  2. Preencha o formulário para configurar o IdP:

    Propriedade Valor
    URL de metadados https://authcloud.trusona.net/.well-known/openid-configuration
    ID do Cliente disponível no portal da Trusona Authentication Cloud
    Segredo do cliente disponível no portal da Trusona Authentication Cloud
    Escopo Perfil e email OpenID
    Tipo de resposta code
    Modo de resposta form_post

  3. Selecione OK.

  4. Clique em Mapear essas declarações do provedor de identidade.

  5. Preencha o formulário para mapear o IdP:

    Propriedade Valor
    UserID sub
    Nome de exibição apelido
    Nome given_name
    Sobrenome family_name
    Modo de resposta email

  6. Selecione OK para concluir a configuração do novo IdP OIDC.

Etapa 4: criar uma política de fluxo de usuário

Agora você deve ver o Trusona como um novo provedor de identidade OpenID Connect listado em seus IdPs B2C.

  1. No locatário do Azure AD B2C, em Políticasselecione Fluxos de usuário.

  2. Selecione Novo fluxo de usuário.

  3. Selecione Inscrever-se e entrar, selecione uma versão e, em seguida, selecione Criar.

  4. Insira um Nome para sua política.

  5. Na seção Provedores de identidade, selecione o Provedor de Identidade – Trusona Authentication Cloud recém-criado.

    Observação

    Como Trusona é inerentemente multifator, é melhor deixar a autenticação multifator desabilitada.

  6. Selecione Criar.

  7. Em Atributos de usuário e declarações, clique em Mostrar mais. No formulário, selecione pelo menos um atributo que você especificou durante a configuração do provedor de identidade na seção anterior.

  8. Selecione OK.

Etapa 5: testar o seu fluxo de usuário

  1. Selecione a política que você criou.

  2. Selecione Executar fluxo de usuário e escolha as configurações:

    a. Aplicativo: selecione o aplicativo registrado, por exemplo, jwt ms.

    b. URL de resposta: selecione a URL de redirecionamento, por exemplo, https://jwt.ms.

  3. Selecione Executar fluxo de usuário. Você deve ser redirecionado para a Trusona Authentication Cloud. O usuário recebe uma página da web de entrada que solicita seu nome de usuário (geralmente um endereço de email). Se a conta do usuário não for encontrada na Trusona Authentication Cloud, uma resposta é enviada ao navegador que inicia um processo de registro WebAuthn no dispositivo. Caso contrário, uma resposta é enviada para o navegador que inicia um processo de autenticação WebAuthn. O usuário é solicitado a selecionar uma credencial a ser usada. A chave de acesso está associada ao domínio do aplicativo web ou a uma chave de segurança do hardware. Depois que o usuário seleciona uma credencial, o sistema operacional solicita que o usuário use uma biometria, senha ou PIN para confirmar sua identidade. Isso desbloqueia o ambiente de Execução Confiável/Enclave Seguro, que gera uma declaração de autenticação assinada pela chave privada associada à credencial selecionada. O Azure AD B2C valida a resposta de autenticação da Trusona e emite um token OIDC. Ele redireciona o usuário de volta para o aplicativo iniciador, por exemplo, https://jwt.ms, que exibe o conteúdo do token retornado pelo Azure AD B2C.

Etapa 3: Criar a chave de política da Trusona Authentication Cloud

Armazene o segredo do cliente que você gerou anteriormente na etapa 1 no seu locatário do Azure AD B2C.

  1. Entre no portal do Azure.

  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o locatário do Azure AD B2C no menu Diretórios + assinaturas.

  3. Escolha Todos os serviços no canto superior esquerdo do Portal do Azure, pesquise Azure AD B2C e selecione-o.

  4. Na página de Visão Geral, selecione Estrutura de Experiência de Identidade.

  5. Selecione Chaves de Política e, em seguida, escolha Adicionar.

  6. Para Opções, escolha Manual.

  7. Insira um Nome para a chave de política. Por exemplo, TrusonaTacClientSecret. O prefixo B2C_1A_ será adicionado automaticamente ao nome da chave.

  8. Em Segredo, insira o segredo do cliente que você registrou anteriormente.

  9. Para Uso de chave, selecione Signature.

  10. Selecione Criar.

Etapa 4: Configurar a Trusona Authentication Cloud como um IdP

Dica

Você deve ter a política Azure AD B2C configurada neste momento. Se este não for o caso, siga as instruções em como obter instruções sobre como configurar seu locatário do Azure AD B2C e configurar políticas.

Para permitir que os usuários entrem usando a Trusona Authentication Cloud, você precisa definir a Trusona como um provedor de declarações com o qual o Azure AD B2C pode se comunicar por meio de um ponto de extremidade. O ponto de extremidade fornece um conjunto de declarações que são usadas pelo Azure AD B2C para verificar se um usuário específico foi autenticado usando a chave de acesso ou a chave de segurança do hardware disponível em seu dispositivo, comprovando a identidade do usuário.

Siga as seguintes etapas para adicionar a Trusona como um provedor de declarações:

  1. Obtenha os pacotes iniciais de políticas personalizadas no GitHub. Em seguida, atualize os arquivos XML no pacote de início de LocalAccounts com nome de seu locatário do Azure AD B2C:

    1. Baixar os arquivos .zip ou clonar o repositório:

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

    2. Em todos os arquivos do diretório LocalAccounts, substitua a cadeia de caracteres yourtenant pelo nome do locatário do Azure AD B2C. Por exemplo, se o nome do locatário do B2C for contoso, todas as instâncias de yourtenant.onmicrosoft.com se transformarão em contoso.onmicrosoft.com.

  2. Abra o LocalAccounts/TrustFrameworkExtensions.xml.

  3. Localize o elemento ClaimsProviders. Caso ele não exista, adicione-o sob o elemento raiz, TrustFrameworkPolicy.

  4. Adicione um novo ClaimsProvider semelhante ao mostrado a seguir:

<ClaimsProvider>
  <Domain>TrusonaTAC</Domain>
  <DisplayName>Trusona TAC</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="TrusonaTAC-OpenIdConnect">
      <DisplayName>TrusonaTAC</DisplayName>
      <Description>Login with your Trusona TAC  account</Description>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
        <Item Key="METADATA">https://authcloud.trusona.net/.well-known/openid-configuration</Item>
        <Item Key="scope">openid profile email</Item>
         <!-- Update the Client ID to the Trusona Authentication Cloud Application ID -->
         <Item Key="client_id">00000000-0000-0000-0000-000000000000</Item>
        <Item Key="response_types">code</Item>
        <Item Key="response_mode">form_post</Item>
        <Item Key="HttpBinding">POST</Item>
        <Item Key="UsePolicyInRedirectUri">false</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="11111111-1111-1111-1111-111111111111"></Item>
        <!-- The key allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs for each tenant. -->
        <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/187f16e9-81ab-4516-8db7-1c8ef94ffeca,https://login.microsoftonline.com/11111111-1111-1111-1111-111111111111</Item>-->
        <!-- The commented key 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>
       <!-- Update the Client Secret to the Trusona Authentication Cloud Client Secret Name -->
        <Key Id="client_secret" StorageReferenceId="B2C_1A_TrusonaTacSecret" />
      </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://authcloud.trusona.net/" />
        <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
        <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
        <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
        <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
        <OutputClaim ClaimTypeReferenceId="email" />
      </OutputClaims>
      <OutputClaimsTransformations>
        <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
        <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
        <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
        <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

  1. Defina client_id com a ID de aplicativo da Trusona Authentication Cloud registrada anteriormente na Etapa 1.

  2. Atualize a seção client_secret com o nome da chave de política criada na Etapa 3. Por exemplo B2C_1A_TrusonaTacClientSecret:

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

  3. Salve as alterações.

Etapa 5: adicionar um percurso do usuário

Você já definiu o IdP, mas ele ainda não está disponível nas páginas de entrada. Se você tiver seu próprio percurso do usuário personalizado, prossiga para a Etapa 6. Caso contrário, crie uma cópia de um modelo existente de percurso do usuário, da seguinte maneira:

  1. Abra o arquivo LocalAccounts/TrustFrameworkBase.xml do pacote inicial.

  2. Localize e copie todo o conteúdo do elemento UserJourney que inclui Id=SignUpOrSignIn.

  3. Abra o LocalAccounts/TrustFrameworkExtensions.xml e encontre o elemento UserJourneys. Se o elemento não existir, adicione um.

  4. Cole todo o conteúdo do elemento UserJourney que você copiou como filho do elemento UserJourneys.

  5. Renomeie o Id do percurso do usuário. Por exemplo, Id=TrusonaTacSUSI.

Etapa 6: Adicionar o IdP a um percurso do usuário

Agora que você tem um percurso do usuário, adicione a ele o novo IdP.

  1. No percurso de usuário, localize o elemento da etapa de orquestração que inclui Type=CombinedSignInAndSignUp ou Type=ClaimsProviderSelection. Normalmente é a primeira etapa de orquestração. O elementoClaimsProviderSelectionscontém uma lista de IdPs que um usuário pode usar para se conectar. A ordem dos elementos controla a ordem dos botões de entrada apresentados para o usuário. Adicione um elemento XML ClaimsProviderSelection. Defina o valor de TargetClaimsExchangeId como um nome amigável, como TrusonaTacExchange.

  2. Na próxima etapa de orquestração, adicione um elemento ClaimsExchange. Defina a ID como o valor da ID de troca de declarações de destino. Atualize o valor de TechnicalProfileReferenceId para a ID do perfil técnico criado anteriormente ao adicionar o provedor de declarações, por exemplo, TrusonaTAC-OpenIdConnect.

O XML a seguir demonstra as etapas de orquestração de uma jornada do usuário com o provedor de identidade:

    <UserJourney Id="TrusonaTacSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="TrusonaTacExchange" />
            <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="TrusonaTacExchange" TechnicalProfileReferenceId="TrusonaTAC-OpenIdConnect" />
            <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 (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>

Saiba mais sobre Percursos do usuário.

Etapa 7: configurar a política de terceira parte confiável

A política de terceira parte confiável, por exemplo SignUpSignIn.xml, especifica a jornada do usuário que o Azure AD B2C executa. Localize o elemento DefaultUserJourney na parte confiável. Atualize a ReferenceId para corresponder à ID do percurso do usuário, na qual você adicionou o provedor de identidade.

No exemplo a seguir, para o percurso do Trusona Authentication Cloud usuário, o ReferenceId é definido como TrusonaTacSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="TrusonaTacSUSI" />
        <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>

Etapa 8: carregar a política personalizada

  1. Entre no portal do Azure.

  2. Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para o locatário do Azure AD B2C no menu Diretórios + assinaturas.

  3. No portal do Azure, pesquise e selecione Azure AD B2C.

  4. Em Políticas, selecione Estrutura de experiência de identidade.

  5. Selecione Carregar política personalizadae, em seguida, carregue os dois arquivos de política que você alterou, na seguinte ordem: a política de extensão, por exemplo TrustFrameworkExtensions.xml, a política de terceira parte confiável, como SignUpOrSignin.xml.

Etapa 9: testar a sua política personalizada

  1. Em seu locatário do Azure AD B2C, em Políticas, selecione Identity Experience Framework.

  2. Em Políticas personalizadas, selecione TrusonaTacSUSI.

  3. Em Aplicativo, selecione o aplicativo Web registrado anteriormente como parte dos pré-requisitos deste artigo. por exemplo, jwt ms. A URL de resposta deve mostrar https://jwt.ms.

  4. Selecione Executar Agora. Seu navegador deve ser redirecionado para a página de entrada da Trusona Authentication Cloud.

  5. Uma tela de entrada é mostrada; na parte inferior deve ser um botão para usar a autenticação Trusona Authentication Cloud.

  6. Você deve ser redirecionado para a Trusona Authentication Cloud. O usuário recebe uma página da web de entrada que solicita seu nome de usuário (geralmente um endereço de email). Se a conta do usuário não for encontrada na Trusona Authentication Cloud, uma resposta é enviada ao navegador que inicia um processo de registro WebAuthn no dispositivo. Caso contrário, uma resposta é enviada para o navegador que inicia um processo de autenticação WebAuthn. O usuário é solicitado a selecionar uma credencial a ser usada. A chave de acesso está associada ao domínio do aplicativo web ou a uma chave de segurança do hardware. Depois que o usuário seleciona uma credencial, o sistema operacional solicita que o usuário use uma biometria, senha ou PIN para confirmar sua identidade. Isso desbloqueia o ambiente de Execução Confiável/Enclave Seguro, que gera uma declaração de autenticação assinada pela chave privada associada à credencial selecionada.

  7. Se o processo de entrada for bem-sucedido, seu navegador será redirecionado para https://jwt.ms, que exibe o conteúdo do token retornado pelo Azure AD B2C.

Próximas etapas

Para obter informações adicionais, examine os seguintes artigos: