Compartilhar via

Configurar o Asignio com o Azure Active 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 em nossas perguntas frequentes.

Saiba como integrar a autenticação do Microsoft Entra ID (Azure AD B2C) ao Asignio. Com essa integração, forneça uma experiência de autenticação multifator, biometria reversível e sem senha aos clientes. O Asignio usa a Assinatura Asignio patenteada e a verificação facial dinâmica para autenticação do usuário. A assinatura biométrica mutável ajuda a reduzir senhas, fraudes, phishing e reutilização de credenciais por meio da autenticação omnicanal.

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 usuário predefinidos
  • Políticas personalizadas configuráveis

As etapas neste artigo diferem para cada método.

Saiba Mais:

Pré-requisitos

  • Uma instância do Azure AD B2C vinculada à assinatura do Azure

  • Confira Tutorial: criar um locatário do Azure Active Directory B2C

  • Uma Identificação de Cliente e uma Chave Secreta do Cliente emitidos pela Asignio.

  • Esses tokens são obtidos registrando seus aplicativos móveis ou Web com o 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

Essa integração inclui os seguintes componentes:

  • Azure AD B2C – servidor de autorização que verifica as credenciais do usuário
  • Aplicativos Web ou móveis – para proteger com o Asignio MFA
  • Aplicativo Web Asignio – coleta biométrica de assinatura no dispositivo de toque do usuário

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 o Asignio usando uma solicitação OIDC (OpenID Connect).
  3. O usuário é redirecionado para o aplicativo Web Asignio para entrada biométrica. 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 usuário autentica-se com Assinatura Asignio e verificação facial, ou verificação facial e de voz.
  5. A resposta do desafio vai para o Asignio.
  6. O Asignio retorna a resposta do OIDC para entrar no Azure AD B2C.
  7. O Azure AD B2C envia uma solicitação de verificação de autenticação ao Asignio para confirmar o recebimento dos dados de autenticação.
  8. O usuário recebe ou nega acesso ao aplicativo.

Configurar um aplicativo com o Asignio

A configuração de um aplicativo com o Asignio é com o site de Administração de Parceiros do Asignio.

  1. Para solicitar acesso à sua organização, acesse asignio.com página Administração de Parceiros do Asignio .
  2. Com as credenciais, entre na Administração de Parceiros da 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 do 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 usará mais tarde. O Asignio não armazena segredos do cliente.
  6. Insira o URI de redirecionamento em seu site para o qual o usuário é retornado 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 um logotipo da empresa. Ele aparece na autenticação do Asignio quando os usuários se conectarem.

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 aplicativo que podem ser usados no Active 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 navegador.

Registrar um aplicativo Web

Conclua as etapas no Tutorial: registrar um aplicativo Web no artigo do Azure Active Directory B2C .

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

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

  1. Entre no Portal do Azure pelo menos como Administrador de Política de IEF B2C do locatário do Azure AD B2C.
  2. Na barra de ferramentas do portal do Azure, selecione Diretórios + assinaturas.
  3. Nas configurações do Portal | Diretórios + assinaturas, na lista de nomes do Diretório , localize o diretório do Microsoft Entra.
  4. Selecione Alternar.
  5. No canto superior esquerdo do portal do Azure, selecione Todos os serviços.
  6. Pesquise e selecione Azure AD B2C.
  7. No portal do Azure, pesquise e selecione Azure AD B2C.
  8. No menu à esquerda, selecione Provedores de identidade.
  9. Selecione Novo Provedor do OpenID Connect.
  10. Selecione o tipo >OpenID Connect.
  11. Para Nome, insira o login do Asignio ou um nome que você escolher.
  12. Para URL de Metadados, insira https://authorization.asignio.com/.well-known/openid-configuration.
  13. Para a ID do cliente, insira a ID do cliente que você gerou.
  14. Para o Segredo do Cliente, insira o Segredo do Cliente gerado.
  15. Em Escopo, use o email de perfil do OpenID.
  16. Para tipo de resposta, use código.
  17. Para modo de resposta, use consulta.
  18. Para dica de domínio, use https://asignio.com.
  19. Selecione OK.
  20. Selecione Mapear as declarações desse provedor de identidade.
  21. Para ID do Usuário, use sub.
  22. Para Nome de Exibição, use nome.
  23. Em Nome, use given_name.
  24. Para Sobrenome, use family_name.
  25. Em Email, use email.
  26. Clique em Salvar.

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 usuário.
  3. Selecione o tipo de fluxo do usuário Inscrever-se e entrar.
  4. Selecione a 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 Nenhum. Essa ação desabilita a autenticação de email e senha.
  8. Para Provedores de identidade personalizados, selecione o provedor de identidade Asignio criado.
  9. Selecione Criar.

Teste o fluxo do usuário

  1. No locatário do Azure AD B2C, selecione Fluxos dos usuários.
  2. Selecione o fluxo de usuário criado.
  3. Para o Aplicativo, selecione o aplicativo Web que você registrou. A URL de Resposta é https://jwt.ms.
  4. Selecione Executar fluxo do usuário.
  5. O navegador é redirecionado para a página de entrada do Asignio.
  6. Uma tela de login é exibida.
  7. Na parte inferior, selecione a autenticação Asignio.

Caso possua uma Assinatura Asignio, conclua o prompt para autenticar. Caso contrário, forneça o número de telefone do dispositivo para autenticar via SMS OTP. Use o link para registrar sua Assinatura do Asignio.

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

Criar chave de configuração do Asignio

  1. Armazene o Segredo do Cliente gerado no locatário do Azure AD B2C.
  2. Entre no portal do Azure.
  3. Na barra de ferramentas do portal, selecione os Diretórios + assinaturas.
  4. Nas configurações do Portal | Diretórios + assinaturas, na lista de nomes do Diretório , localize o diretório do Azure AD B2C.
  5. Selecione Alternar.
  6. No canto superior esquerdo do portal do Azure, selecione Todos os serviços.
  7. Pesquise 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. Para Opções, selecione Manual.
  12. Insira um Nome para a chave de política. O prefixo B2C_1A_ é acrescentado ao nome da chave.
  13. Em Segredo, insira o Segredo do Cliente que você anotou.
  14. Para Uso de chave, selecione Assinatura.
  15. Selecione Criar.

Configurar o Asignio como um provedor de identidade

Dica

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

Para que os usuários entrem usando o Asignio, defina o Asignio como provedor de declarações com o qual o Azure AD B2C se comunica por meio de um ponto de extremidade. O ponto de extremidade fornece as declarações usadas pelo Azure AD B2C para verificar a autenticação do usuário com uma ID digital no seu dispositivo.

Adicionar o 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 o nome do locatário do Azure AD B2C.

  1. Baixe o arquivo 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. Localize 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 a 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.

Adicione um percurso de usuário

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

  1. Se você tiver um percurso de usuário personalizado, continue configurando a política de terceira parte confiável, caso contrário, copie um percurso do usuário de modelo:
  2. No pacote inicial, abra o LocalAccounts/TrustFrameworkBase.xml.
  3. Localize e copie o conteúdo do elemento UserJourney que inclua Id=SignUpOrSignIn.
  4. Abra o LocalAccounts/TrustFrameworkExtensions.xml.
  5. Localize o elemento UserJourneys . Se não houver um, adicione um.
  6. Cole o conteúdo do elemento UserJourney como filho do elemento UserJourneys.]
  7. Renomeie a ID do percurso do usuário. Por exemplo, Id=AsignioSUSI.

Saiba mais: Percursos do usuário

Adicione o provedor de identidade a um percurso de usuário

Adicione o novo provedor de identidade ao percurso do usuário.

  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 elemento ClaimsProviderSelections tem uma lista de provedores de identidade com a qual os usuários entrarão. A ordem dos elementos controla a ordem dos botões de entrada.
  2. Adicione um elemento XML ClaimsProviderSelection.
  3. Defina o valor de TargetClaimsExchangeId com um nome amigável.
  4. Adicione um elemento ClaimsExchange .
  5. Defina a ID como o valor da ID de troca de declarações de destino.
  6. Atualize o valor de TechnicalProfileReferenceId para a ID do perfil técnico criado.

O XML a seguir demonstra a orquestração de percurso 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 de terceira parte confiável

A política de terceira parte confiável, por exemplo SignUpSignIn.xml, especifica o percurso do usuário que o Azure AD B2C executa.

  1. Na terceira parte confiável, localize o elemento DefaultUserJourney.
  2. 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 AsignioSUSI usuário, o ReferenceId é definido 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. Entre no portal do Azure.
  2. Na barra de ferramentas do portal, selecione os Diretórios + assinaturas.
  3. Nas configurações do Portal | Diretórios + assinaturas, na lista de nomes do Diretório , localize o diretório do Azure AD B2C.
  4. Selecione Alternar.
  5. No portal do Azure, pesquise 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 que você alterou na seguinte ordem:
  • Política de extensão, por exemplo TrustFrameworkExtensions.xml
  • Política de terceira 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. Para o Aplicativo, selecione o aplicativo Web que você registrou. A URL de Resposta é https://jwt.ms.
  4. Selecione Executar agora.
  5. O navegador é redirecionado para a página de entrada do Asignio.
  6. Uma tela de login é exibida.
  7. Na parte inferior, selecione a autenticação Asignio.

Se você tiver uma Assinatura Asignio, será solicitado que você se autentique com sua Assinatura Asignio. Caso contrário, forneça o número de telefone do dispositivo para autenticar via SMS OTP. Use o link para registrar sua Assinatura do Asignio.

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

Próximas etapas

  • Last updated on