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

Artigo
01/26/2024

Saiba como integrar a autenticação da ID do Microsoft Entra (Azure AD B2C) ao Asignio. Com essa integração, forneça experiência de autenticação multifator sem senha e biometria reversível para clientes. O Asignio usa uma assinatura Asignio patenteada e verificação facial dinâmica para autenticação do usuário. A assinatura biométrica alterável para 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 desse artigo são diferentes para cada método.

Saiba mais:

Pré-requisitos

Uma assinatura do Azure.
Se você não tiver, obtenha uma conta gratuita do Azure

Um locatário do Azure AD B2C vinculado à assinatura do Azure.
Confira Tutorial: criar um locatário do Azure Active Directory B2C
Uma ID do cliente Asignio e um Segredo do Cliente emitido pela Asignio.
Esses tokens são obtidos registrando seus aplicativos móveis ou Web com o Asignio.

Para políticas personalizadas

Complete Tutorial: Criar fluxos dos usuários e políticas personalizadas no Azure Active Directory B2C

Descrição do cenário

Esta integração inclui os seguintes componentes:

Azure AD B2C – o 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: – coleção biométrica de assinatura no dispositivo touch do usuário

O diagrama a seguir ilustra a implementação.

Diagrama mostrando a arquitetura da implementação.

O usuário abre a página de entrada do Azure AD B2C no seu aplicativo móvel ou Web e, em seguida, entra ou se inscreve.
O Azure AD B2C redireciona o usuário para Asignio usando uma solicitação OIDC (OpenID Connect).
O usuário é redirecionado para o aplicativo Web Asignio para a entrada biométrica. Se o usuário não tiver registrado sua Assinatura Asignio, ele poderá usar um SMS com senha única (OTP) para autenticar. Após a autenticação, o usuário recebe um link de registro para criar sua Assinatura Asignio.
O usuário se autentica com sua Assinatura Asignio e verificação facial ou verificação de voz e facial.
A resposta do desafio vai para o Asignio.
O Asignio retorna a resposta OIDC para entrar no Azure AD B2C.
Azure AD B2C envia uma solicitação de verificação de autenticação ao Asignio para confirmar o recebimento dos dados de autenticação.
O usuário tem acesso concedido ou negado ao aplicativo.

Configurar um aplicativo com Asignio

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

Acesse a página de Administração de Parceiros da Asignio asignio.com para solicitar acesso à sua organização.
Com as credenciais, entre na Administração de Parceiros da Asignio.
Crie um registro para o aplicativo Azure AD B2C usando seu locatário Azure AD B2C. Quando o Azure AD B2C é usado com o Asignio, Azure AD B2C gerencia seus aplicativos conectados. Os aplicativos Asignio representam aplicativos no portal do Azure.
No site de Administração de Parceiros do Asignio, gere uma ID do cliente e um segredo do cliente.
Anote e armazene a ID do Cliente e o Segredo do Cliente. Você os usará mais tarde. O Asignio não armazena o Segredo do Cliente.
Insira o URI de redirecionamento no site para o qual o usuário retornará após a autenticação. Use o padrão de URI a seguir.

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

Carregar um logotipo da empresa. Ele aparece na autenticação do Asignio quando os usuários se conectam.

Registrar um aplicativo Web no Azure AD B2C

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

Saiba mais: Tipos de aplicativos 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 e habilitar a concessão implícita de token de ID

Complete o Tutorial: Registrar um aplicativo Web no 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.

Entre no portal do Azure como Administrador Global do locatário do Azure AD B2C.
Na barra de ferramentas do portal do Azure, selecione Diretórios + assinaturas.
Em Configurações do portal | Diretórios + assinaturas, na lista Nome do diretório, localize seu diretório do Microsoft Entra.
Selecione Alternar.
No canto superior esquerdo do portal do Azure, selecione Todos os serviços.
Pesquise e selecione Azure AD B2C.
No portal do Azure, pesquise e selecione Azure AD B2C.
No painel esquerdo, selecione Provedores de identidade.
Selecione Novo provedor do OpenID Connect.
Selecione o Tipo de provedor de identidade>OpenID Connect.
Em Nome, insira a entrada do Asignio ou um nome que você escolher.
Em URL de metadados, insira https://authorization.asignio.com/.well-known/openid-configuration.
Para ID do Cliente, insira a ID do Cliente que você gerou.
Para Segredo do Cliente , insira o Segredo do Cliente que você gerou.
Em Escopo, use o email de perfil do OpenID.
Em Tipo de resposta, use código.
Em Modo de resposta, use query.
Para Dica de domínio, use https://asignio.com.
Selecione OK.
Selecione Mapear essas declarações do provedor de identidade.
Para ID do Usuário, use sub.
Para Exibir nome, use name.
Em Nome, use given_name.
Em Sobrenome, use family_name.
Em Email, use email.
Selecione Salvar.

SCriar uma política de fluxo de usuário

No locatário do Azure AD B2C, em Políticasselecione Fluxos de usuário.
Selecione Novo fluxo de usuário.
Selecione o tipo de fluxo de usuário Inscrever-se e entrar.
Selecione Versão Recomendada.
Selecione Criar.
Insira o fluxo de usuário Nome, como AsignioSignupSignin.
Em Provedores de identidade, para Contas Locais, selecione Nenhum. Essa ação desabilita a autenticação por email e senha.
Para provedores de identidade personalizados, selecione o provedor de identidade Asignio criado.
Selecione Criar.

Testar seu fluxo de usuário

No locatário do Azure AD B2C, selecione Fluxos dos usuários.
Selecione o fluxo de usuário criado.
Para Aplicativo, selecione o aplicativo Web registrado na etapa 1. A URL de resposta é https://jwt.ms.
Selecione Executar fluxo de usuário.
O navegador é redirecionado para a página de entrada do Asignio.
Uma tela de entrada é exibida.
Na parte inferior, selecione Autenticação Asignio .

Se você tiver uma Assinatura do 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.

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

Crie uma chave de política do Asignio

Armazene o Segredo do Cliente gerado no locatário do Azure AD B2C.
Entre no portal do Azure.
Na barra de ferramentas do portal, selecione Diretórios + assinaturas.
Na página Configurações do portal, Diretórios + assinaturas, na lista Nome do diretório, localize o diretório Azure AD B2C.
Selecione Alternar.
No canto superior esquerdo do portal do Azure, selecione Todos os serviços.
Pesquise e selecione Azure AD B2C.
Na página de Visão Geral, selecione Estrutura de Experiência de Identidade.
Selecione Chaves de Política.
Selecione Adicionar.
Em Opções selecione Manual.
Insira um Nome para a chave de política. O prefixo B2C_1A_ é adicionado ao nome da chave.
Em Segredo, insira o Segredo do Cliente que você anotou.
Para Uso de chave, selecione Assinatura.
Selecione Criar.

Configure o Asignio como um provedor de identidade

Dica

Antes de começar, verifique se a política Azure AD B2C está configurada. Caso contrário, siga as instruções no Pacote 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 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:

Baixe o zip active-directory-b2c-custom-policy-starterpack-main ou clone o repositório:

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

Em todos os arquivos do diretório LocalAccounts, substitua a cadeia de caracteres yourtenant pelo nome do locatário do Azure AD B2C.
Abra o LocalAccounts/TrustFrameworkExtensions.xml.
Localize o elemento ClaimsProviders. Se não houver um, adicione-o no elemento raiz, TrustFrameworkPolicy.

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">00000000-0000-0000-0000-000000000000</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="22222222-2222-2222-2222-222222222222"></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/11111111-1111-1111-1111-111111111111</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>

Defina o client_id com sua ID do Aplicativo Asignio.
Atualize a seção client_secret com a chave de política que você criou. Por exemplo B2C_1A_AsignioSecret:
```
<Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
```
Salve as alterações.

Adicione um percurso de usuário

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

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:
No pacote inicial, abra LocalAccounts/ TrustFrameworkBase.xml.
Localize e copie todo o conteúdo do elemento UserJourney que inclui Id=SignUpOrSignIn.
Abra o LocalAccounts/TrustFrameworkExtensions.xml.
Localize o elemento UserJourneys. Se não houver um, adicione um.
Cole o conteúdo do elemento UserJourney como filho do elemento UserJourneys.]
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.

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 possui uma lista de provedores de identidade com os quais os usuários se conectam. A ordem dos elementos controla a ordem dos botões de entrada que o usuário vê.
Adicione um elemento XML ClaimsProviderSelection.
Defina o valor de TargetClaimsExchangeId com um nome amigável.
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 você criou.

O XML a seguir demonstra as etapas de orquestração de uma 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 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.

Na terceira parte confiável, localize o elemento DefaultUserJourney.
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

Entre no portal do Azure.
Na barra de ferramentas do portal, selecione Diretórios + assinaturas.
Na página Configurações do portal, Diretórios + assinaturas, na lista Nome do diretório, localize o diretório Azure AD B2C.
Selecione Alternar.
No portal do Azure, pesquise e selecione Azure AD B2C.
Em Políticas, selecione Estrutura de experiência de identidade.
Selecione Carregar Política Personalizada.
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

Em seu locatário do Azure AD B2C e, em Políticas, selecione Identity Experience Framework.
Em Políticas personalizadas, selecione AsignioSUSI.
Para Aplicativo, selecione o aplicativo Web registrado. A URL de resposta é https://jwt.ms.
Selecione Executar Agora.
O navegador é redirecionado para a página de entrada do Asignio.
Uma tela de entrada é exibida.
Na parte inferior, selecione Autenticação Asignio .

Se você tiver uma assinatura Asignio, será solicitado que você autentique usando a 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.

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

Compartilhar via