Configurar o Trusona Authentication Cloud com o Azure Ative Directory B2C

Artigo
01/26/2024

Neste tutorial de exemplo, você aprenderá a integrar a autenticação B2C do Azure AD com o Trusona Authentication Cloud. É um serviço baseado na nuvem que permite aos utilizadores autenticarem-se com uma experiência tap-and-go , sem a necessidade de qualquer tipo de aplicação autenticadora móvel.

Os benefícios da integração do Trusona Authentication Cloud com o Azure AD B2C incluem:

Forneça autenticação forte com uma melhor experiência do usuário
- Utilizadores mais felizes que gastam mais online
- Menor desgaste e abandono, aumento das receitas
- Maior retenção, valor vitalício (LTV)
Menor custo de funcionamento do negócio
- Redução das aquisições e da partilha 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
Elimine palavras-passe
- Não há mais 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, precisa do seguinte:

Uma conta de avaliação do Trusona Authentication Cloud. Para solicitar uma conta, entre em contato com a Trusona.
Uma subscrição do Azure. Se não tiver uma subscrição, pode obter uma conta gratuita.
Um locatário do Azure AD B2C vinculado à sua assinatura do Azure.

Conclua as etapas no artigo Introdução às políticas personalizadas no Azure AD B2C.

Descrição do cenário

Padrão de autenticação da Web - WebAuthn implementa sistemas operacionais modernos e navegadores para suportar a autenticação via impressão digital, Windows hello ou dispositivos FIDO externos, como USB, Bluetooth e OTP.

Nesse cenário, Trusona atua como um provedor de identidade (IdP) para Azure AD B2C para habilitar a autenticação sem senha. Os seguintes componentes compõem a solução:

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

Screenshot shows Trusona architecture diagram.

Passos	Description
1.	Um utilizador tenta iniciar sessão na aplicação Web através do seu 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 para o Trusona Authentication Cloud OpenID Connect (OIDC) IdP.
4.	É apresentada ao utilizador uma página Web de início de sessão que pede o seu nome de utilizador – normalmente um endereço de e-mail.
5.	O usuário insere seu endereço de e-mail e seleciona o botão Continuar . Se a conta do usuário não for encontrada na Trusona Authentication Cloud, uma resposta será enviada para o navegador que inicia um processo de registro WebAuthn no dispositivo. Caso contrário, uma resposta será enviada para o navegador que inicia um processo de autenticação WebAuthn.
6.	O usuário é solicitado a selecionar uma credencial para usar. A chave de acesso está associada ao domínio do aplicativo Web ou a uma chave de segurança de 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 Secure Enclave/Trusted Execution, que gera uma declaração de autenticação assinada pela chave privada associada à credencial selecionada.
7.	A declaração de autenticação é devolvida ao serviço de nuvem Trusona para verificação.
8.	Uma vez verificado, o Trusona Authentication Cloud (IdP) cria um token de ID 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 configuraçã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 inicial 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 B2C do Azure AD. 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 é concedido/negado ao usuário.

Etapa 1: Integre com o Trusona Authentication Cloud

Inicie sessão no Portal Trusona.
No painel de navegação esquerdo, selecione Configurações
No menu Configurações, selecione o controle deslizante para Ativar OIDC.
Selecione as entradas apropriadas e forneça o URLhttps://{your-tenant-name}.b2clogin.com/{your-tenant-name}.onmicrosoft.com/oauth2/authresp de redirecionamento.
Gere uma chave secreta e copie a chave para uso em sua configuração do Azure AD B2C.
Nota
1. O portal Trusona suporta o registo self-service. Ao registar-se, ser-lhe-á atribuída uma conta Trusona com direitos só de leitura. Posteriormente, a Trusona irá atribuir-lhe a conta correta e elevar os seus direitos de leitura-escrita com base na política de controlo de acesso da sua organização para os utilizadores do portal.
2. O nome de domínio inicial do Microsoft Entra ID é usado como host de redirecionamento do cliente.

Etapa 2: Registrar um aplicativo Web no Azure AD B2C

Antes que seus aplicativos possam interagir com o Azure AD B2C, eles devem 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 sai do seu navegador). Para registrar um aplicativo Web em seu locatário do Azure AD B2C, use nossa nova experiência de registro de aplicativo unificado.

Inicie sessão no portal do Azure.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
No portal do Azure, procure e selecione Azure AD B2C.
Selecione Registos de aplicações e, em seguida, selecione Novo registo.
Insira um Nome para o aplicativo. Por exemplo, jwt ms.
Em Tipos de conta suportados, selecione Contas em qualquer provedor de identidade ou diretório organizacional (para autenticar usuários com fluxos de usuários).
Em Redirecionar URI, selecione Web e digite https://jwt.ms a caixa de texto URL.

O URI de redirecionamento é o ponto de extremidade para o qual o servidor de autorização, Azure AD B2C, neste caso, envia o usuário. Depois de concluir sua 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 acessível publicamente onde seu aplicativo está sendo executado, como https://contoso.com/auth-response. Para fins de teste como este tutorial, você pode defini-lo como 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 sai do seu navegador). Durante o desenvolvimento do aplicativo, você pode adicionar o ponto de extremidade onde seu aplicativo escuta localmente, como https://localhost:5000. Você pode adicionar e modificar URIs de redirecionamento em seus aplicativos registrados a qualquer momento.

As seguintes restrições se aplicam aos URIs de redirecionamento:
- A URL de resposta deve começar com o esquema https, a menos que você use uma URL de redirecionamento localhost.
- O URL de resposta diferencia maiúsculas de minúsculas. Seu caso deve corresponder ao caso do caminho da URL do seu aplicativo em execução. Por exemplo, se seu aplicativo incluir como parte de seu caminho .../abc/response-oidc, não especifique .../ABC/response-oidc na URL de resposta. Como o navegador da Web trata os caminhos como diferenciadores de maiúsculas e minúsculas, os cookies associados podem .../abc/response-oidc ser excluídos se redirecionados para o URL incompatível com maiúsculas e minúsculas .../ABC/response-oidc .
- O URL de resposta deve incluir ou excluir a barra à direita conforme o seu aplicativo espera. Por exemplo, https://contoso.com/auth-response e https://contoso.com/auth-response/ podem ser tratados como URLs não correspondentes em seu aplicativo.
Em Permissões, marque a caixa de seleção Conceder consentimento de administrador para permissões openid e offline_access .
Selecione Registar.

Habilitar concessão implícita de token de ID

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

No menu à esquerda, em Gerenciar, selecione Autenticação.
Em Concessão implícita e fluxos híbridos, marque as caixas de seleção Tokens de ID (usados para fluxos implícitos e híbridos).
Selecione Guardar.

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

Inicie sessão no portal do Azure como administrador global do inquilino do Azure AD B2C.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
Escolha Todos os serviços no canto superior esquerdo do portal do Azure, procure e selecione Azure AD B2C.
Navegue até Dashboard>Azure Ative Directory B2C>Identity providers.
Selecione Provedores de identidade.
Selecione Adicionar.

Configurar um IdP

Selecione Tipo de provedor de>identidade OpenID Connect (Visualização).

Preencha o formulário para configurar o IdP:

Property	Valor
URL de metadados	`https://authcloud.trusona.net/.well-known/openid-configuration`
ID de Cliente	disponível no portal Trusona Authentication Cloud
Segredo do cliente	disponível no portal Trusona Authentication Cloud
Scope	E-mail do perfil OpenID
Tipo de resposta	code
Modo de resposta	form_post

Selecione OK.
Selecione Mapear as declarações deste provedor de identidade.
Preencha o formulário para mapear o IdP:

Property Valor

UserID sub

Display name alcunha

Nome próprio given_name

Apelido family_name

Modo de resposta Correio eletrónico
Selecione OK para concluir a configuração do seu novo IdP OIDC.

Property	Valor
UserID	sub
Display name	alcunha
Nome próprio	given_name
Apelido	family_name
Modo de resposta	Correio eletrónico

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.

Em seu locatário do Azure AD B2C, em Políticas, selecione Fluxos de usuário.
Selecione Novo fluxo de utilizador.
Selecione Inscrever-se e iniciar sessão, selecione uma versão e, em seguida, selecione Criar.
Introduza um Nome para a sua política.
Na seção Provedores de identidade, selecione seu recém-criado Trusona Authentication Cloud-Identity Provider.

Nota

Como o Trusona é inerentemente multifator, é melhor deixar a autenticação multifator desativada.
Selecione Criar.
Em Atributos e Declarações do Usuário, escolha Mostrar mais. No formulário, selecione pelo menos um atributo que você especificou durante a configuração do seu provedor de identidade na seção anterior.
Selecione OK.

Etapa 5: Testar o fluxo de usuários

Selecione a política que criou.
Selecione Executar fluxo de usuário e, em seguida, selecione as configurações:

a. Aplicação: Selecione o aplicativo registrado, por exemplo, jwt ms.

b. URL de resposta: selecione o URL de redirecionamento, por exemplo, https://jwt.ms.
Selecione Executar fluxo de utilizador. Você deve ser redirecionado para o Trusona Authentication Cloud. É apresentada ao utilizador uma página Web de início de sessão que pede o seu nome de utilizador – normalmente um endereço de e-mail. Se a conta do usuário não for encontrada no Trusona Authentication Cloud, uma resposta será enviada para o navegador que inicia um processo de registro WebAuthn no dispositivo. Caso contrário, uma resposta será enviada para o navegador que inicia um processo de autenticação WebAuthn. O usuário é solicitado a selecionar uma credencial para usar. A chave de acesso está associada ao domínio do aplicativo Web ou a uma chave de segurança de 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 Secure Enclave/Trusted Execution, que gera uma asserção de autenticação assinada pela chave privada associada à credencial selecionada. O Azure AD B2C valida a resposta de autenticação Trusona e emite um token OIDC. Ele redireciona o usuário de volta para o aplicativo inicial, por exemplo, , https://jwt.msque exibe o conteúdo do token retornado pelo Azure AD B2C.

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

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

Inicie sessão no portal do Azure.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
Escolha Todos os serviços no canto superior esquerdo do portal do Azure e, em seguida, procure e selecione Azure AD B2C.
Na página Visão geral, selecione Identity Experience Framework.
Selecione Chaves de política e, em seguida, selecione Adicionar.
Em Opções, escolha Manual.
Insira um Nome para a chave de política. Por exemplo, TrusonaTacClientSecret. O prefixo B2C_1A_ é adicionado automaticamente ao nome da sua chave.
Em Segredo, insira o segredo do cliente que você gravou anteriormente.
Para Uso da chave, selecione Signature.
Selecione Criar.

Etapa 4: Configurar o Trusona Authentication Cloud como um IdP

Gorjeta

Você deve ter a política do Azure AD B2C configurada neste momento. Caso contrário, siga as instruções sobre como configurar seu locatário do Azure AD B2C e configurar políticas.

Para permitir que os usuários entrem usando o Trusona Authentication Cloud, você precisa definir o 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 se autenticou usando uma chave de acesso ou uma chave de segurança de hardware disponível em seu dispositivo, comprovando a identidade do usuário.

Use as seguintes etapas para adicionar o Trusona como um provedor de declarações:

Obtenha os pacotes iniciais de políticas personalizadas do GitHub e, em seguida, atualize os arquivos XML no pacote inicial LocalAccounts com seu nome de locatário do Azure AD B2C:
1. Faça o download do arquivo .zip ou clone o repositório:
```
    git clone https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack
```
2. Em todos os arquivos no diretório LocalAccounts , substitua a cadeia de caracteres yourtenant pelo nome do locatário do Azure AD B2C. Por exemplo, se o nome do seu locatário B2C for contoso, todas as instâncias de yourtenant.onmicrosoft.com tornar-se-ão contoso.onmicrosoft.com.
Abra o LocalAccounts/TrustFrameworkExtensions.xml.
Encontre o elemento ClaimsProviders . Se não existir, adicione-o sob o elemento raiz, TrustFrameworkPolicy.
Adicione um novo ClaimsProvider semelhante ao mostrado da seguinte forma:

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

Defina client_id com o ID do aplicativo Trusona Authentication Cloud que você registrou anteriormente na etapa 1.
Atualize client_secret seção 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" />
```
Guarde as alterações.

Etapa 5: Adicionar uma jornada do usuário

Neste ponto, você configurou o IdP, mas ele ainda não está disponível em nenhuma das páginas de login. Se você tiver sua própria jornada de usuário personalizada, continue para a Etapa 6, caso contrário, crie uma duplicata de uma jornada de usuário de modelo existente da seguinte maneira:

Abra o LocalAccounts/TrustFrameworkBase.xml ficheiro a partir do starter pack.
Localize e copie todo o conteúdo do elemento UserJourney que inclui Id=SignUpOrSignIno .
Abra o e localize o LocalAccounts/TrustFrameworkExtensions.xmlelemento UserJourneys . Se o elemento não existir, adicione um.
Cole todo o conteúdo do elemento UserJourney que você copiou como filho do elemento UserJourneys.
Renomeie a Id jornada do usuário. Por exemplo, Id=TrusonaTacSUSI.

Etapa 6: Adicionar o IdP a uma jornada do usuário

Agora que você tem uma jornada do usuário, adicione o novo IdP à jornada do usuário.

Encontre o elemento da etapa de orquestração que inclui Type=CombinedSignInAndSignUpo , ou Type=ClaimsProviderSelection na jornada do usuário. Geralmente é o primeiro passo da orquestração. O elemento ClaimsProviderSelections contém uma lista de IdPs com os quais um usuário pode entrar. A ordem dos elementos controla a ordem dos botões de entrada apresentados ao usuário. Adicione um elemento XML ClaimsProviderSelection . Defina o valor de TargetClaimsExchangeId como um nome amigável, como TrusonaTacExchange.
Na próxima etapa de orquestração, adicione um elemento ClaimsExchange . Defina o Id como o valor do 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 as Jornadas 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. Encontre o elemento DefaultUserJourney na terceira parte confiável. Atualize o ReferenceId para corresponder ao ID de jornada do usuário, no qual você adicionou o provedor de identidade.

No exemplo a seguir, para a jornada 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

Inicie sessão no portal do Azure.
Se você tiver acesso a vários locatários, selecione o ícone Configurações no menu superior para alternar para seu locatário do Azure AD B2C no menu Diretórios + assinaturas .
No portal do Azure, procure e selecione Azure AD B2C.
Em Políticas, selecione Identity Experience Framework.
Selecione Carregar Política Personalizada e, em seguida, carregue os dois ficheiros de política que alterou, pela seguinte ordem: a política de extensão, por exemplo TrustFrameworkExtensions.xml, e, em seguida, a política de entidade confiadora, como SignUpOrSignin.xml.

Etapa 9: Testar sua política personalizada

Em seu locatário do Azure AD B2C, em Políticas, selecione Identity Experience Framework.
Em Políticas personalizadas, selecione TrusonaTacSUSI.
Em Aplicativo, selecione o aplicativo Web que você registrou anteriormente como parte dos pré-requisitos deste artigo. por exemplo jwt ms. O URL de resposta deve mostrar https://jwt.ms.
Selecione Executar agora. Seu navegador deve ser redirecionado para a página de login do Trusona Authentication Cloud.
É apresentado um ecrã de início de sessão; na parte inferior deve haver um botão para usar a autenticação Trusona Authentication Cloud .
Você deve ser redirecionado para Trusona Authentication Cloud. É apresentada ao utilizador uma página Web de início de sessão que pede o seu nome de utilizador – normalmente um endereço de e-mail. Se a conta do usuário não for encontrada na Trusona Authentication Cloud, uma resposta será enviada para o navegador que inicia um processo de registro WebAuthn no dispositivo. Caso contrário, uma resposta será enviada para o navegador que inicia um processo de autenticação WebAuthn. O usuário é solicitado a selecionar uma credencial para usar. A chave de acesso está associada ao domínio do aplicativo Web ou a uma chave de segurança de 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 Secure Enclave/Trusted Execution, que gera uma asserção de autenticação assinada pela chave privada associada à credencial selecionada.
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óximos passos

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

Partilhar via