Partilhar via

Configurar o Asignio com o Azure Ative Directory B2C para autenticação multifator

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.

Aprenda a integrar a autenticação do Microsoft Entra ID (Azure AD B2C) com o Asignio. Com essa integração, forneça aos clientes uma experiência de autenticação sem senha, biométrica flexível e multifator. Asignio usa assinatura patenteada Asignio e verificação facial ao vivo para autenticação do usuário. A assinatura biométrica alterável ajuda a reduzir senhas, fraudes, phishing e reutilização de credenciais por meio da autenticação omnichannel.

Antes de começar

Escolha um seletor de tipo de política para indicar a configuração do tipo de política. O Azure AD B2C tem dois métodos para definir como os usuários interagem com seus aplicativos:

  • Fluxos de utilizador predefinidos
  • Políticas personalizadas configuráveis

As etapas neste artigo diferem para cada método.

Saiba mais:

Pré-requisitos

  • Um locatário do Azure AD B2C vinculado à assinatura do Azure

  • Consulte Tutorial: Criar um tenant B2C do Azure Active Directory

  • Um ID de Cliente Asignio e um Segredo do Cliente emitidos pela Asignio.

  • Estes tokens são obtidos através do registo das suas aplicações móveis ou web com a Asignio.

Para políticas personalizadas

Tutorial completo: Criar fluxos de usuário e políticas personalizadas no Azure AD B2C

Descrição do cenário

Esta integração inclui os seguintes componentes:

  • Azure AD B2C - servidor de autorização que verifica as credenciais do usuário
  • Aplicações Web ou móveis - para proteger com Asignio MFA
  • Aplicação web Asignio - recolha biométrica de assinaturas no dispositivo táctil do utilizador

O diagrama a seguir ilustra a implementação.

Diagrama mostrando a arquitetura de implementação.

  1. O usuário abre a página de entrada do Azure AD B2C em seu aplicativo móvel ou Web e, em seguida, entra ou se inscreve.
  2. O Azure AD B2C redireciona o usuário para Asignio usando uma solicitação OpenID Connect (OIDC).
  3. O utilizador é redirecionado para a aplicação web Asignio para iniciar sessão através de biometria. Se o usuário não registrou sua assinatura Asignio, ele pode usar um SMS One-Time-Password (OTP) para autenticar. Após a autenticação, o usuário recebe um link de registro para criar sua assinatura Asignio.
  4. O utilizador autentica-se com a assinatura Asignio e verificação facial, ou verificação de voz e facial.
  5. A resposta do desafio vai para Asignio.
  6. Asignio retorna a resposta OIDC para entrar no Azure AD B2C.
  7. O Azure AD B2C envia uma solicitação de verificação de autenticação para Asignio para confirmar o recebimento dos dados de autenticação.
  8. O usuário recebe ou nega acesso ao aplicativo.

Configurar um aplicativo com Asignio

A configuração de uma aplicação com o Asignio é feita no site de Administração de Parceiros do Asignio.

  1. Para solicitar acesso para sua organização, vá para asignio.com página Administração de parceiros Asignio .
  2. Inicie sessão com as credenciais na Administração de Parceiros Asignio.
  3. Crie um registro para o aplicativo Azure AD B2C usando seu locatário do Azure AD B2C. Quando você usa o Azure AD B2C com o Asignio, o Azure AD B2C gerencia aplicativos conectados. Os aplicativos Asignio representam aplicativos no portal do Azure.
  4. No site de Administração de Parceiros Asignio, gere uma ID do Cliente e um Segredo do Cliente.
  5. Anote e armazene a ID do Cliente e o Segredo do Cliente. Você os usa mais tarde. Asignio não armazena segredos do cliente.
  6. Insira o URI de redirecionamento em seu site para o qual o usuário retornará após a autenticação. Use o seguinte padrão de URI.

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

  1. Carregue o logótipo de uma empresa. Ele aparece na autenticação Asignio quando os usuários fazem login.

Registrar um aplicativo Web no Azure AD B2C

Registre aplicativos em um locatário que você gerencia e, em seguida, eles podem interagir com o Azure AD B2C.

Saiba mais: Tipos de aplicativos que podem ser usados no Ative Directory B2C

Para este tutorial, você está registrando https://jwt.ms, um aplicativo Web da Microsoft com conteúdo de token decodificado que não sai do seu navegador.

Registar uma aplicação Web

Conclua as etapas no artigo Tutorial: Registrar um aplicativo Web no Azure Ative Directory B2C .

Configurar o Asignio como um provedor de identidade no Azure AD B2C

Para obter as instruções a seguir, use o locatário do Microsoft Entra com a assinatura do Azure.

  1. Entre no portal do Azure como pelo menos Administrador de Políticas IEF B2C do locatário do Azure AD B2C.
  2. Na barra de ferramentas do portal do Azure, selecione Diretórios + assinaturas.
  3. Configurações do Portal | Diretórios + assinaturas, na lista Nome do diretório , localize o diretório Microsoft Entra.
  4. Selecione Trocar.
  5. No canto superior esquerdo do portal do Azure, selecione Todos os serviços.
  6. Procure e selecione Azure AD B2C.
  7. No portal do Azure, procure e selecione Azure AD B2C.
  8. No menu à esquerda, selecione Provedores de identidade.
  9. Selecione Novo Provedor OpenID Connect.
  10. Selecione tipo de provedor de identidade>OpenID Connect.
  11. Em Nome, insira o login Asignio ou um nome que você escolher.
  12. Para URL de metadados, digite https://authorization.asignio.com/.well-known/openid-configuration.
  13. Em ID do cliente, insira a ID do cliente gerada.
  14. Em Segredo do Cliente, insira o Segredo do Cliente gerado.
  15. Para Escopo, use o perfil de e-mail openid.
  16. Para Tipo de resposta, use código.
  17. Para o modo de resposta, use query.
  18. Utilize a indicação de domínio https://asignio.com.
  19. Selecione OK.
  20. Selecione Mapeie as declarações deste provedor de identidade.
  21. Para a identificação de utilizador , use sub.
  22. Para Nome de Exibição, utilize nome.
  23. Para Nome Próprio, usar nome_próprio.
  24. Para Sobrenome, use nome_familia.
  25. Para Email, use email.
  26. Selecione Guardar.

Criar uma política de fluxo de usuário

  1. Em seu locatário do Azure AD B2C, em Políticas, selecione Fluxos de usuário.
  2. Selecione Novo fluxo de utilizador.
  3. Selecione o tipo de fluxo de utilizador Inscrever-se e iniciar sessão.
  4. Selecione Versão recomendada.
  5. Selecione Criar.
  6. Insira um nome de fluxo de usuário, como AsignioSignupSignin.
  7. Em Provedores de identidade, para Contas locais, selecione Nenhuma. Esta ação desativa a autenticação de e-mail e senha.
  8. Em Provedores de identidade personalizados, selecione o provedor de identidade Asignio criado.
  9. Selecione Criar.

Teste seu fluxo de usuários

  1. Em seu locatário do Azure AD B2C, selecione Fluxos de usuário.
  2. Selecione o fluxo de usuário criado.
  3. Em Aplicativo, selecione o aplicativo Web que você registrou. O URL de resposta é https://jwt.ms.
  4. Selecione Executar fluxo de utilizador.
  5. O navegador é redirecionado para a página de login Asignio.
  6. É apresentado um ecrã de início de sessão.
  7. No fundo, selecione Autenticação Asignio.

Se você tiver uma assinatura Asignio, conclua o prompt para autenticar. Caso contrário, forneça o número de telefone do dispositivo para autenticação via SMS OTP. Use o link para registrar sua assinatura Asignio.

  1. O navegador é redirecionado para https://jwt.ms. O conteúdo do token retornado pelo Azure AD B2C aparece.

Criar chave de política Asignio

  1. Armazene o Segredo de Cliente gerado no locatário do Azure AD B2C.
  2. Inicie sessão no portal Azure.
  3. Na barra de ferramentas do portal, selecione o Diretórios + Subscrições.
  4. Configurações do Portal | Diretórios + assinaturas, na lista Nome do diretório , localize seu diretório do Azure AD B2C.
  5. Selecione Trocar.
  6. No canto superior esquerdo do portal do Azure, selecione Todos os serviços.
  7. Procure e selecione Azure AD B2C.
  8. Na página Visão geral, selecione Identity Experience Framework.
  9. Selecione Chaves de política.
  10. Selecione Adicionar.
  11. Em Opções, selecione Manual.
  12. Insira uma chave de política Nome para a chave de política. O prefixo B2C_1A_ é anexado ao nome da chave.
  13. Em Segredo, insira o Segredo do Cliente que você anotou.
  14. Para o uso da chave , selecione Assinatura .
  15. Selecione Criar.

Configurar Asignio como um provedor de identidade

Sugestão

Antes de começar, verifique se a política do Azure AD B2C está configurada. Caso contrário, siga as instruções em Pacote inicial de política personalizada.

Para que os utilizadores entrem com o Asignio, defina o Asignio como um fornecedor de reivindicações com o qual o Azure AD B2C se comunica através de um endpoint. O ponto de extremidade fornece declarações que o Azure AD B2C usa para verificar a autenticação do usuário usando a ID digital no dispositivo.

Adicionar Asignio 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. Descarregue o ficheiro zip active-directory-b2c-custom-policy-starterpack ou clone o repositório:

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

  2. Nos arquivos no diretório LocalAccounts , substitua a cadeia de caracteres yourtenant pelo nome do locatário do Azure AD B2C.

  3. Abra o LocalAccounts/ TrustFrameworkExtensions.xml.

  4. Encontre o elemento ClaimsProviders. Se não houver um, adicione-o sob o elemento raiz, TrustFrameworkPolicy.

  5. Adicione um novo ClaimsProvider semelhante ao exemplo a seguir:

     <ClaimsProvider>
   <Domain>contoso.com</Domain>
   <DisplayName>Asignio</DisplayName>
   <TechnicalProfiles>
     <TechnicalProfile Id="Asignio-Oauth2">
       <DisplayName>Asignio</DisplayName>
       <Description>Login with your Asignio account</Description>
       <Protocol Name="OAuth2" />
       <Metadata>
         <Item Key="ProviderName">authorization.asignio.com</Item>
         <Item Key="authorization_endpoint">https://authorization.asignio.com/authorize</Item>
         <Item Key="AccessTokenEndpoint">https://authorization.asignio.com/token</Item>
         <Item Key="ClaimsEndpoint">https://authorization.asignio.com/userinfo</Item>
         <Item Key="ClaimsEndpointAccessTokenName">access_token</Item>
         <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
         <Item Key="HttpBinding">POST</Item>
         <Item Key="scope">openid profile email</Item>
         <Item Key="UsePolicyInRedirectUri">0</Item>
         <!-- Update the Client ID below to the Asignio Application ID -->
         <Item Key="client_id">00001111-aaaa-2222-bbbb-3333cccc4444</Item>
         <Item Key="IncludeClaimResolvingInClaimsHandling">true</Item>


         <!-- trying to add additional claim-->
         <!--Insert b2c-extensions-app application ID here, for example: 00001111-aaaa-2222-bbbb-3333cccc4444-->
         <Item Key="00001111-aaaa-2222-bbbb-3333cccc4444"></Item>
         <!--Insert b2c-extensions-app application ObjectId here, for example: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb-->
         <Item Key="aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"></Item>
         <!-- The key below allows you to specify each of the Azure AD tenants that can be used to sign in. Update the GUIDs below for each tenant. -->
         <!--<Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/00001111-aaaa-2222-bbbb-3333cccc4444</Item>-->
         <!-- The commented key below specifies that users from any tenant can sign-in. Uncomment if you would like anyone with an Azure AD account to be able to     sign in. -->
         <Item Key="ValidTokenIssuerPrefixes">https://login.microsoftonline.com/</Item>
       </Metadata>
       <CryptographicKeys>
         <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
       </CryptographicKeys>
       <OutputClaims>
         <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="sub" />
         <OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
         <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
         <OutputClaim ClaimTypeReferenceId="identityProvider" PartnerClaimType="iss" DefaultValue="https://authorization.asignio.com" />
         <OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
         <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
         <OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
         <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
         <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" />
       </OutputClaims>
       <OutputClaimsTransformations>
         <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
         <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
         <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
         <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
       </OutputClaimsTransformations>
       <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
     </TechnicalProfile>
   </TechnicalProfiles>
 </ClaimsProvider>

  6. Defina client_id com o ID do aplicativo Asignio que você anotou.

  7. Atualize client_secret seção com a chave de política que você criou. Por exemplo: B2C_1A_AsignioSecret

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

  8. Salve as alterações.

Adicionar uma jornada do utilizador

O provedor de identidade não está nas páginas de login.

  1. Se você tiver uma jornada de usuário personalizada, continue para Configurar a política do partido confiável; caso contrário, copie uma jornada de usuário a partir de um modelo.
  2. No pacote inicial, abra o LocalAccounts/ TrustFrameworkBase.xml.
  3. Localize e copie o conteúdo do elemento UserJourney que inclui Id=SignUpOrSignIn.
  4. Abra o LocalAccounts/ TrustFrameworkExtensions.xml.
  5. Localize o elemento UserJourneys. Se não houver, adicione um.
  6. Cole o conteúdo do elemento UserJourney como filho do elemento UserJourneys.]
  7. Renomeie o ID da jornada do utilizador. Por exemplo, Id=AsignioSUSI.

Saiba mais: Jornadas do usuário

Adicionar o provedor de identidade a um percurso do utilizador

Adicione o novo provedor de identidade à jornada do usuário.

  1. Encontre o elemento da etapa de orquestração que inclui Type=CombinedSignInAndSignUp ou Type=ClaimsProviderSelection na jornada do utilizador. Geralmente é o primeiro passo da orquestração. O elemento ClaimsProviderSelections tem uma lista de provedores de identidade com a qual os usuários entram. A ordem dos elementos controla a ordem dos botões de entrada.
  2. Adicione um ClaimsProviderSelection elemento XML.
  3. Defina o valor de TargetClaimsExchangeId como um nome amigável.
  4. Adicione um elemento ClaimsExchange .
  5. Defina o Id como o valor do ID de troca de declarações de destino.
  6. Atualize o valor de TechnicalProfileReferenceId para a ID do perfil técnico que você criou.

O XML a seguir demonstra a orquestração da jornada do usuário com o provedor de identidade.

    <UserJourney Id="AsignioSUSI">
      <OrchestrationSteps>
        <OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
          <ClaimsProviderSelections>
            <ClaimsProviderSelection TargetClaimsExchangeId="AsignioExchange" />
            <ClaimsProviderSelection ValidationClaimsExchangeId="LocalAccountSigninEmailExchange" />
          </ClaimsProviderSelections>
          <ClaimsExchanges>
            <ClaimsExchange Id="LocalAccountSigninEmailExchange" TechnicalProfileReferenceId="SelfAsserted-LocalAccountSignin-Email" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Check if the user has selected to sign in using one of the social providers -->
        <OrchestrationStep Order="2" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AsignioExchange" TechnicalProfileReferenceId="Asignio-Oauth2" />
            <ClaimsExchange Id="SignUpWithLogonEmailExchange" TechnicalProfileReferenceId="LocalAccountSignUpWithLogonEmail" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="3" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>localAccountAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). This can only happen when authentication happened using a social IDP. If local account was created or authentication done using ESTS in step 2, then an user account must exist in the directory by this time. -->
        <OrchestrationStep Order="4" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- This step reads any user attributes that we may not have received when authenticating using ESTS so they can be sent            in the token. -->
        <OrchestrationStep Order="5" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimEquals" ExecuteActionsIf="true">
              <Value>authenticationSource</Value>
              <Value>socialIdpAuthentication</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect from the user. So, in that case, create the user in the directory if one does not already exist (verified using objectId which would be set from the last step if account was created in the directory. -->
        <OrchestrationStep Order="6" Type="ClaimsExchange">
          <Preconditions>
            <Precondition Type="ClaimsExist" ExecuteActionsIf="true">
              <Value>objectId</Value>
              <Action>SkipThisOrchestrationStep</Action>
            </Precondition>
          </Preconditions>
          <ClaimsExchanges>
            <ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
          </ClaimsExchanges>
        </OrchestrationStep>
        <OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
      </OrchestrationSteps>
      <ClientDefinition ReferenceId="DefaultWeb" />
    </UserJourney>

Configurar a política da parte confiadora

A política da parte confiável, por exemplo, SignUpSignIn.xml, especifica a experiência do utilizador que o Azure AD B2C executa.

  1. Na parte de confiança, localize o elemento DefaultUserJourney.
  2. Atualize o ReferenceId para corresponder ao ID de trajetória do utilizador, em que adicionou o fornecedor de identidade.

No exemplo seguinte, para o percurso do AsignioSUSI utilizador, o ReferenceId é configurado como AsignioSUSI:

   <RelyingParty>
        <DefaultUserJourney ReferenceId="AsignioSUSI" />
        <TechnicalProfile Id="PolicyProfile">
          <DisplayName>PolicyProfile</DisplayName>
          <Protocol Name="OpenIdConnect" />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="displayName" />
            <OutputClaim ClaimTypeReferenceId="givenName" />
            <OutputClaim ClaimTypeReferenceId="surname" />
            <OutputClaim ClaimTypeReferenceId="email" />
            <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
            <OutputClaim ClaimTypeReferenceId="identityProvider" />
            <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
            <OutputClaim ClaimTypeReferenceId="correlationId" DefaultValue="{Context:CorrelationId}" />
          </OutputClaims>
          <SubjectNamingInfo ClaimType="sub" />
        </TechnicalProfile>
      </RelyingParty>

Carregar a política personalizada

  1. Inicie sessão no portal Azure.
  2. Na barra de ferramentas do portal, selecione o Diretórios + Subscrições.
  3. Configurações do Portal | Diretórios + assinaturas, na lista Nome do diretório , localize seu diretório do Azure AD B2C.
  4. Selecione Trocar.
  5. No portal do Azure, procure e selecione Azure AD B2C.
  6. Em Políticas, selecione Identity Experience Framework.
  7. Selecione Carregar política personalizada.
  8. Carregue os dois arquivos de política alterados na seguinte ordem:
  • Política de extensão, por exemplo TrustFrameworkExtensions.xml
  • Política de parte confiável, como SignUpOrSignin.xml

Testar sua política personalizada

  1. Em seu locatário do Azure AD B2C e em Políticas, selecione Identity Experience Framework.
  2. Em Políticas personalizadas, selecione AsignioSUSI.
  3. Em Aplicativo, selecione o aplicativo Web que você registrou. O URL de resposta é https://jwt.ms.
  4. Selecione Executar agora.
  5. O navegador é redirecionado para a página de login Asignio.
  6. É apresentado um ecrã de início de sessão.
  7. No fundo, selecione Autenticação Asignio.

Se tiver uma Assinatura Asignio, ser-lhe-á pedido que se autentique com a sua Assinatura Asignio. Caso contrário, forneça o número de telefone do dispositivo para autenticação via SMS OTP. Use o link para registrar sua assinatura Asignio.

  1. O navegador é redirecionado para https://jwt.ms. O conteúdo do token retornado pelo Azure AD B2C aparece.

Próximos passos

  • Last updated on