Partilhar via


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

Saiba como integrar a autenticação Microsoft Entra ID (Azure AD B2C) com o Asignio. Com esta integração, forneça experiência de autenticação multifator e biométrica sem palavra-passe e sem palavra-passe aos clientes. O Asignio utiliza a Assinatura Asignio patenteada e a verificação facial em direto para a autenticação do utilizador. A assinatura biométrica alterável ajuda a reduzir palavras-passe, fraude, phishing e reutilização de credenciais através 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. Azure AD B2C tem dois métodos para definir a forma como os utilizadores interagem com as suas aplicações:

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

Os passos neste artigo diferem para cada método.

Saiba mais:

Pré-requisitos

Para políticas personalizadas

Tutorial Completo: Criar fluxos de utilizador 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 utilizador
  • Aplicações Web ou móveis – para proteger com a MFA do Asignio
  • Aplicação Web Asignio – coleção biométrica de assinatura no dispositivo tátil do utilizador

O diagrama seguinte ilustra a implementação.

Diagrama a mostrar a arquitetura de implementação.

  1. O utilizador abre Azure AD página de início de sessão B2C na respetiva aplicação móvel ou Web e, em seguida, inicia sessão ou inscreve-se.
  2. Azure AD B2C redireciona o utilizador para o Asignio com um pedido openID Connect (OIDC).
  3. O utilizador é redirecionado para a aplicação Web Asignio para iniciar sessão biométrica. Se o utilizador não tiver registado a respetiva Assinatura asignio, pode utilizar um SMS One-Time-Password (OTP) para autenticar. Após a autenticação, o utilizador recebe uma ligação de registo para criar a respetiva Assinatura Asignio.
  4. O utilizador autentica-se com Asignio Signature e verificação facial, ou verificação de voz e facial.
  5. A resposta ao desafio vai para Asignio.
  6. Asignio devolve a resposta OIDC ao Azure AD início de sessão B2C.
  7. Azure AD B2C envia um pedido de verificação de autenticação para o Asignio para confirmar a receção dos dados de autenticação.
  8. É concedido ou negado acesso ao utilizador à aplicação.

Configurar uma aplicação com o Asignio

Configurar uma aplicação com o Asignio é com o site de Administração de Parceiros do Asignio.

  1. Aceda a asignio.com página Administração de Parceiros do Asignio para pedir acesso à sua organização.
  2. Com as credenciais, inicie sessão na Administração de Parceiros do Asignio.
  3. Crie um registo para o Azure AD aplicação B2C com o seu inquilino Azure AD B2C. Quando utiliza Azure AD B2C com o Asignio, Azure AD B2C gere aplicações ligadas. As aplicações asignio representam aplicações no portal do Azure.
  4. No site Administração de Parceiros do Asignio, gere um ID de Cliente e Um Segredo do Cliente.
  5. Anote e armazene o ID de Cliente e o Segredo do Cliente. Irá utilizá-los mais tarde. O Asignio não armazena Segredos do Cliente.
  6. Introduza o URI de redirecionamento no seu site ao qual o utilizador é devolvido após a autenticação. Utilize o seguinte padrão de URI.

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

  1. Carregar um logótipo da empresa. Aparece na autenticação Asignio quando os utilizadores iniciam sessão.

Registar uma aplicação Web no Azure AD B2C

Registe aplicações num inquilino que gere e, em seguida, podem interagir com Azure AD B2C.

Saiba mais: Tipos de aplicações que podem ser utilizados no Active Directory B2C

Neste tutorial, está a registar , uma aplicação https://jwt.msWeb da Microsoft com conteúdos de tokens descodificados que não saem do browser.

Registar uma aplicação Web e ativar a concessão implícita de tokens de ID

Tutorial Completo: Registar uma aplicação Web no Azure Active Directory B2C

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

Para obter as seguintes instruções, utilize o inquilino Microsoft Entra com a subscrição do Azure.

  1. Inicie sessão no portal do Azure como Administrador Global do inquilino do Azure AD B2C.
  2. Na barra de ferramentas portal do Azure, selecione Diretórios + subscrições.
  3. Definições do portal | Diretórios + subscrições, na lista Nome do diretório, localize o seu diretório Microsoft Entra.
  4. Selecione Mudar.
  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 esquerdo, selecione Fornecedores de identidade.
  9. Selecione Novo Fornecedor de Ligação OpenID.
  10. Selecione Fornecedor de identidade tipo>OpenID Connect.
  11. Em Nome, introduza o início de sessão do Asignio ou um nome que escolher.
  12. Para o URL de Metadados, introduza https://authorization.asignio.com/.well-known/openid-configuration.
  13. Para o ID de Cliente, introduza o ID de Cliente que gerou.
  14. Para Segredo do Cliente, introduza o Segredo do Cliente que gerou.
  15. Em Âmbito, utilize o perfil de e-mail openid.
  16. Para Tipo de resposta, utilize código.
  17. Para o Modo de resposta, utilize a consulta.
  18. Para sugestão de domínio, utilize https://asignio.com.
  19. Selecione OK.
  20. Selecione Mapear as afirmações deste fornecedor de identidade.
  21. Para O ID de Utilizador, utilize o sub.
  22. Para Nome a Apresentar, utilize o nome.
  23. Para Nome Especificado, utilize given_name.
  24. Para Apelido, utilize family_name.
  25. Para Email, utilize o e-mail.
  26. Selecione Guardar.

SCriar uma política de fluxo de utilizador

  1. Na sua Azure AD inquilino B2C, em Políticas, selecione Fluxos de utilizador.
  2. Selecione Novo fluxo de utilizador.
  3. Selecione Inscrever-se e inicie sessão no tipo de fluxo de utilizador.
  4. Selecione Versão Recomendada.
  5. Selecione Criar.
  6. Introduza um nome de fluxo de utilizador, como AsignioSignupSignin.
  7. Em Fornecedores de identidade, para Contas Locais, selecione Nenhuma. Esta ação desativa a autenticação por e-mail e palavra-passe.
  8. Para Fornecedores de identidade personalizados, selecione o fornecedor de Identidade Asignio criado.
  9. Selecione Criar.

Testar o fluxo de utilizador

  1. No seu Azure AD inquilino B2C, selecione Fluxos de utilizador.
  2. Selecione o fluxo de utilizador criado.
  3. Em Aplicação, selecione a aplicação Web que registou. O URL de Resposta é https://jwt.ms.
  4. Selecione Executar fluxo de utilizador.
  5. O browser é redirecionado para a página de início de sessão do Asignio.
  6. É apresentado um ecrã de início de sessão.
  7. Na parte inferior, selecione Autenticação asignio .

Se tiver uma Assinatura asignio, conclua o pedido de autenticação. Caso contrário, forneça o número de telefone do dispositivo para autenticar através de SMS OTP. Utilize a ligação para registar a Sua Assinatura de Asignio.

  1. O browser é redirecionado para https://jwt.ms. Os conteúdos do token devolvidos pelo Azure AD B2C são apresentados.

Criar chave de política do Asignio

  1. Armazene o Segredo do Cliente gerado no inquilino Azure AD B2C.
  2. Inicie sessão no portal do Azure.
  3. Na barra de ferramentas do portal, selecione Diretórios + subscrições.
  4. Definições do portal | Diretórios + subscrições, na lista Nome do diretório, localize a sua Azure AD diretório B2C.
  5. Selecione Mudar.
  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 Descrição geral, selecione Identity Experience Framework.
  9. Selecione Chaves de Política.
  10. Selecione Adicionar.
  11. Para Opções, selecione Manual.
  12. Introduza uma chave de política Nome para a chave de política. O prefixo B2C_1A_ é anexado ao nome da chave.
  13. Em Segredo, introduza o Segredo do Cliente que anotou.
  14. Para Utilização de chaves, selecione Assinatura.
  15. Selecione Criar.

Configurar o Asignio como um fornecedor de Identidade

Dica

Antes de começar, certifique-se de que o Azure AD política B2C está configurado. Caso contrário, siga as instruções no pacote De arranque da política personalizada.

Para que os utilizadores iniciem sessão com o Asignio, defina o Asignio como um fornecedor de afirmações com o qual Azure AD B2C comunica através de um ponto final. O ponto final fornece afirmações Azure AD B2C utiliza para verificar a autenticação do utilizador com o ID digital no dispositivo.

Adicionar o Asignio como um fornecedor de afirmações

Obtenha os pacotes de iniciação de políticas personalizadas a partir do GitHub e, em seguida, atualize os ficheiros XML no pacote inicial LocalAccounts com o seu nome de inquilino Azure AD B2C:

  1. Transfira o 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 ficheiros no diretório LocalAccounts, substitua a cadeia yourtenant pelo Azure AD nome do inquilino B2C.

  3. Abra a TrustFrameworkExtensions.xmlLocalAccounts/ .

  4. Localize o elemento ClaimsProviders . Se não existir uma, adicione-a no elemento raiz , TrustFrameworkPolicy.

  5. Adicione um novo ClaimsProvider semelhante ao exemplo seguinte:

     <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>
    
  6. Defina client_id com o ID da Aplicação Asignio que anotou.

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

    <Key Id="client_secret" StorageReferenceId="B2C_1A_AsignioSecret" />
    
  8. Guarde as alterações.

Adicionar um percurso de utilizador

O fornecedor de identidade não está nas páginas de início de sessão.

  1. Se tiver um percurso de utilizador personalizado, continue para Configurar a política de entidade confiadora, caso contrário, copie um percurso de utilizador de modelo:
  2. A partir do pacote de arranque, abra o TrustFrameworkBase.xmlLocalAccounts/ .
  3. Localize e copie o conteúdo do elemento UserJourney que inclui Id=SignUpOrSignIn.
  4. Abra a TrustFrameworkExtensions.xmlLocalAccounts/ .
  5. Localize o elemento UserJourneys . Se não existir uma, adicione uma.
  6. Cole o conteúdo do elemento UserJourney como um subordinado do elemento UserJourneys.]
  7. Mude o nome do ID de percurso do utilizador. Por exemplo, Id=AsignioSUSI.

Saiba mais: Percursos de utilizador

Adicionar o fornecedor de identidade a um percurso de utilizador

Adicione o novo fornecedor de identidade ao percurso do utilizador.

  1. Localize o elemento do passo de orquestração que inclui Type=CombinedSignInAndSignUpou Type=ClaimsProviderSelection no percurso do utilizador. Normalmente é o primeiro passo de orquestração. O elemento ClaimsProviderSelections tem uma lista de fornecedores de identidade com a qual os utilizadores iniciam sessão. A ordem dos elementos controla a ordem dos botões de início de sessão.
  2. Adicione um elemento ClaimsProviderSelection XML.
  3. Defina o valor de TargetClaimsExchangeId como um nome amigável.
  4. Adicione um elemento ClaimsExchange .
  5. Defina o ID para o valor do ID de troca de afirmações de destino.
  6. Atualize o valor de TechnicalProfileReferenceId para o ID do perfil técnico que criou.

O XML seguinte demonstra a orquestração de percursos de utilizador com o fornecedor 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 entidade confiadora

A política de entidade confiadora, por exemplo SignUpSignIn.xml, especifica o percurso do utilizador Azure AD B2C é executado.

  1. Na entidade confiadora, localize o elemento DefaultUserJourney .
  2. Atualize o ReferenceId para corresponder ao ID de percurso do utilizador, no qual adicionou o fornecedor de identidade.

No exemplo seguinte, para o percurso do AsignioSUSI utilizador, o ReferenceId está 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. Inicie sessão no portal do Azure.
  2. Na barra de ferramentas do portal, selecione Diretórios + subscrições.
  3. Definições do portal | Diretórios + subscrições, na lista Nome do diretório, localize a sua Azure AD diretório B2C.
  4. Selecione Mudar.
  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 ficheiros de política que alterou pela seguinte ordem:
  • Política de extensão, por exemplo TrustFrameworkExtensions.xml
  • Política de entidade confiadora, como SignUpOrSignin.xml

Testar a sua política personalizada

  1. No seu Azure AD inquilino B2C e, em Políticas, selecione Identity Experience Framework.
  2. Em Políticas personalizadas, selecione AsignioSUSI.
  3. Em Aplicação, selecione a aplicação Web que registou. O URL de Resposta é https://jwt.ms.
  4. Selecione Executar agora.
  5. O browser é redirecionado para a página de início de sessão do Asignio.
  6. É apresentado um ecrã de início de sessão.
  7. Na parte inferior, 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 autenticar através de SMS OTP. Utilize a ligação para registar a sua Assinatura Asignio.

  1. O browser é redirecionado para https://jwt.ms. Os conteúdos do token devolvidos pelo Azure AD B2C são apresentados.

Passos seguintes