Usar o Microsoft Entra MFA com um provedor externo (versão prévia)

Este artigo descreve como um provedor de autenticação externa se conecta à MFA (autenticação multifator) do Microsoft Entra.

Quando um usuário entra, as políticas de locatário são avaliadas. Os requisitos de autenticação são determinados com base no recurso que o usuário tenta acessar.

Várias políticas poderão se aplicar ao login, dependendo de seus parâmetros. Esses parâmetros incluem usuários e grupos, aplicativos, a plataforma, o nível de risco de entrada e muito mais.

Com base nos requisitos de autenticação, talvez o usuário precise entrar com outro fator para atender ao requisito de MFA. O tipo do segundo fator precisa complementar o tipo do primeiro fator.

O administrador do locatário adiciona métodos de autenticação externa à ID do Microsoft Entra. Se um locatário exigir um método de autenticação externa para MFA, a entrada será considerada para atender ao requisito de MFA depois que a ID do Microsoft Entra validar ambos:

• O primeiro fator foi concluído com o Microsoft Entra.
• O segundo fator foi concluído com o método de autenticação externa.

Essa validação atende ao requisito de MFA para dois ou mais tipos de métodos:

• Algo que você conhece (conhecimento)
• Algo que você tem (posse)
• Algo que você é (inerência)

Os métodos de autenticação externa são implementados sobre o OpenID Connect (OIDC). Essa implementação requer pelo menos três pontos de extremidade expostos publicamente para implementar um método de autenticação externa.

• Um ponto de extremidade de Descoberta OIDC, conforme descrito em Descoberta de metadados do provedor
• Um ponto de extremidade de autenticação OIDC válido
• Uma URL onde os certificados públicos do provedor são publicados

Veja como a entrada funciona com um método de autenticação externa:

1. Um usuário tenta entrar com um primeiro fator, como uma senha, para um aplicativo protegido pelo Microsoft Entra ID.

2. A ID do Microsoft Entra determina que outro fator precisa ser atendido (por exemplo, se uma política de Acesso Condicional exigir MFA).

3. O usuário escolhe o método de autenticação externa como um segundo fator.

4. A ID do Microsoft Entra redireciona a sessão do navegador do usuário para a URL do método de autenticação externa.

   Essa URL é descoberta pela URL de descoberta que um administrador provisionou quando criou o método de autenticação externa.

   O aplicativo fornece um token expirado ou quase expirado que contém informações para identificar o usuário e o locatário.

5. O provedor de autenticação externa valida se o token veio do Microsoft Entra ID e verifica o conteúdo do token.

6. O provedor de autenticação externa pode fazer uma chamada ao Microsoft Graph para buscar informações adicionais sobre o usuário.

7. O provedor de autenticação externa executa todas as ações que considerar necessárias, como autenticar o usuário com uma credencial.

8. O provedor de autenticação externa redireciona o usuário de volta para a ID do Microsoft Entra com um token válido, incluindo todas as declarações necessárias.

9. O Microsoft Entra ID valida que a assinatura do token veio do provedor de autenticação externa configurado e depois verifica o conteúdo do token.

10. O Microsoft Entra ID valida o token em relação aos requisitos.

11. Se a validação for bem-sucedida, isso significa que o usuário cumpriu o requisito de MFA. O usuário também pode ter que atender a outros requisitos de política.

Configurando um novo provedor de autenticação externa com a ID do Microsoft Entra

Para emitir id_token_hint, os métodos de autenticação externa precisam de um aplicativo que represente a integração. Você pode criar o aplicativo de duas maneiras:

• Em cada cliente que utiliza o provedor externo.
• Como um único aplicativo multilocatário. Para habilitar a integração para seu locatário, os administradores de função com privilégios precisam conceder consentimento.

O uso de um aplicativo multilocatário pode reduzir a chance de configuração incorreta em cada locatário. Os provedores também podem fazer alterações nos metadados (por exemplo, URLs de resposta em um só lugar), em vez de exigir que cada locatário faça as alterações.

Para configurar um aplicativo multilocatário, o administrador do provedor deve primeiro:

1. Crie um tenant do Microsoft Entra ID (se ainda não tiverem um).

2. Registrar um aplicativo em seu locatário.

3. No aplicativo, em tipos de conta com suporte, selecione Contas em qualquer diretório organizacional (qualquer locatário da ID do Microsoft Entra – Multilocatário).

4. Adicione os valores de permissão delegada openid e profile para o Microsoft Graph.

5. Não publicar nenhum escopo nesse aplicativo.

6. Adicione as URLs válidas authorization_endpoint do provedor de identidade externa a esse aplicativo como URLs de resposta.

   Observação

   No registro do aplicativo, adicione o authorization_endpoint valor fornecido no documento de descoberta do provedor como uma URL de redirecionamento. Caso contrário, você receberá o seguinte erro: "ENTRA IDSTS50161: falha ao validar a URL de autorização do provedor de declarações externas!"

O processo de registro de aplicativo cria um aplicativo com várias propriedades. Você precisa dessas propriedades para nosso cenário.

Outro modelo válido para dar suporte à integração é usar um aplicativo para cada locatário. Se você usar um registro de inquilino único, o administrador do inquilino precisa criar um registro de aplicativo com as propriedades da tabela anterior para um aplicativo de inquilino único.

Configurar declarações opcionais

Um provedor pode configurar mais declarações usando declarações opcionais para id_token.

Adicionando um método de autenticação externa à ID do Microsoft Entra

As informações do provedor de identidade externa são armazenadas na política de métodos de autenticação de cada locatário. As informações do provedor são armazenadas como um método de autenticação do tipo externalAuthenticationMethodConfiguration.

Cada provedor tem uma entrada na lista de objetos da política. Cada entrada precisa declarar:

• Se o método estiver habilitado.
• Os grupos incluídos que podem usar o método.
• Os grupos excluídos que não podem usar o método.

Para definir o requisito de MFA para a entrada do usuário, os usuários com a função administrador de acesso condicional podem criar uma política com a concessão Exigir MFA. Atualmente, não há suporte para os métodos de autenticação externa com pontos fortes de autenticação.

Saiba mais sobre como adicionar um método de autenticação externa no Centro de administração do Microsoft Entra.

Interação do Microsoft Entra ID com o provedor

As próximas seções explicam os requisitos do provedor e incluem exemplos de como a ID do Microsoft Entra interage com um provedor.

Descoberta de metadados do provedor

Um provedor de identidade externa precisa fornecer um Ponto de extremidade de descoberta OIDC. Esse endpoint é usado para obter mais dados de configuração.

A URL de descoberta deve usar o https esquema e deve terminar com /.well-known/openid-configuration. Você não pode incluir segmentos de caminho adicionais, cadeias de caracteres de consulta ou fragmentos após esse segmento. A URL de descoberta completa deve ser incluída na URL de descoberta que você configura ao criar o método de autenticação externa.

O endpoint retorna um documento JSON de metadados do provedor hospedado lá. O endpoint também deve retornar um cabeçalho Content-Length válido. O documento de metadados deve estar em conformidade com o OpenID Connect Discovery 1.0 (incorporando o conjunto errata 2) e incluir todos os campos de metadados OIDC necessários.

Os metadados do provedor precisam incluir os dados listados na tabela a seguir. Esses valores são necessários para esse cenário de extensibilidade. O documento de metadados JSON pode conter mais informações.

Para o documento OIDC que tem os valores para metadados do provedor, consulte metadados do provedor.

https://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
  "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
  "claims_supported": [
    "email"
  ],
  "grant_types_supported": [
    "implicit"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "issuer": "https://customcaserver.azurewebsites.net/v2.0",
  "jwks_uri": "https://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

https://customcaserver.azurewebsites.net/.well-known/jwks
{
  "keys": [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
      "e": "AQAB",
      "x5c": [
        "cZa3jz...Wo0rzA="
      ]
    }
  ]
}

Exemplos de URL de descoberta e de emissor

Os exemplos a seguir ilustram combinações válidas e inválidas de URL de descoberta e emissor para essa integração.

URL de descoberta válida e pares emissores

• URL de descoberta: https://example.com/.well-known/openid-configuration
  Emissor: https://example.com
• URL de descoberta: https://example.com:8443/.well-known/openid-configuration
  Emissor: https://example.com:8443
• URL de descoberta: https://example.com/tenant1/.well-known/openid-configuration
  Emissor: https://example.com/tenant1

Exemplos inválidos de URL de descoberta e de emissor.

• URL de descoberta: https://example.com/.well-known/openid-configuration
  Emissor: https://example.com:443/ (porta HTTPS padrão explicitamente adicionada no emissor.)
• URL de descoberta: https://example.com:443/.well-known/openid-configuration
  Emissor: https://example.com/ (Incompatibilidade de porta.)
• URL de descoberta: https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
  Emissor: https://example.com (Você não pode incluir uma cadeia de caracteres de consulta em uma URL de descoberta.)

Cache de metadados do provedor

Para melhorar o desempenho, a ID do Microsoft Entra armazena em cache os metadados que o provedor retorna, incluindo as chaves. O cache de metadados do provedor evita a necessidade de uma chamada de descoberta sempre que o Microsoft Entra ID se comunica com um provedor de identidade externo.

Esse cache é atualizado a cada 24 horas. Recomendamos que os provedores sigam estas etapas para entregar suas chaves:

1. Publicar o Certificado Existente e o Novo Certificado em jwks_uri.
2. Continue a entrar com o Certificado Existente até que o cache do ID do Microsoft Entra seja atualizado, expirado ou renovado (a cada 2 dias).
3. Alterne para fazer login com o Novo Cert.

Não publicamos cronograma para substituições de chaves. O serviço dependente deve estar preparado para lidar com rotações imediatas e periódicas. Sugerimos o uso de uma biblioteca dedicada criada para essa finalidade, como azure-activedirectory-identitymodel-extensions-for-dotnet. Para obter mais informações, consulte Substituição de chave de assinatura no Microsoft Entra ID.

Descoberta de metadados do Microsoft Entra ID

Os provedores também precisam recuperar as chaves públicas do Microsoft Entra ID para validar os tokens emitidos pelo Microsoft Entra ID.

Pontos de extremidade de descoberta dos metadados do Microsoft Entra ID:

• Azure global: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Azure para o Governo dos EUA: https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
• Microsoft Azure operado pela 21Vianet: https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

Você pode usar o identificador de chave pública do token (o "kid" da Assinatura Web JSON (JWS)) para determinar qual das chaves recuperadas da propriedade jwks_uri deve ser usada para validar a assinatura do token do Microsoft Entra ID.

Validando tokens emitidos pelo Microsoft Entra ID

Para obter informações sobre como validar os tokens emitidos pela ID do Microsoft Entra, consulte Validar um token de ID. Não há etapas específicas para os consumidores de nossos metadados de descoberta.

Você pode encontrar todos os detalhes sobre a validação de token na biblioteca de validação de token da Microsoft. Você também pode verificar esses detalhes navegando pelo código-fonte. Para obter um exemplo, confira Exemplos do Azure.

Depois que a validação for bem-sucedida, você poderá trabalhar com o conteúdo das declarações para obter detalhes sobre o usuário e seu locatário.

Chamada do Microsoft Entra ID para um provedor de identidade externa

O Microsoft Entra ID usa o fluxo implícito de OIDC para se comunicar com o provedor de identidade externo. Quando você utiliza esse fluxo, a comunicação com o provedor ocorre apenas por meio do endpoint de autorização do provedor.

Para informar o provedor sobre o usuário para quem a ID do Microsoft Entra está fazendo a solicitação, a ID do Microsoft Entra passa um token por meio do id_token_hint parâmetro.

Essa chamada é feita por meio de uma POST solicitação porque uma grande lista de parâmetros é passada para o provedor. Uma lista grande impede o uso de navegadores que limitam o comprimento de uma solicitação GET .

Os parâmetros de solicitação de autenticação são listados na tabela a seguir.

Exemplo de um URI de redirecionamento

Os URIs de redirecionamento devem ser registrados com o provedor fora da banda. Os URIs de redirecionamento que você pode enviar são:

• Azure global: https://login.microsoftonline.com/common/federation/externalauthprovider
• Azure para o Governo dos EUA: https://login.microsoftonline.us/common/federation/externalauthprovider
• Microsoft Azure operado pela 21Vianet: https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

Exemplo de um método de autenticação externa que satisfaz a MFA

Aqui está um exemplo em que um método de autenticação externa atende aos requisitos de MFA. Este exemplo ajuda um provedor a saber quais declarações o Microsoft Entra ID espera.

O ID do Microsoft Entra usa a combinação dos valores acr e amr para validar que:

• O método de autenticação usado para o segundo fator atende ao requisito de MFA.
• O método de autenticação é um tipo diferente do método usado para completar o primeiro fator de login no Microsoft Entra ID.

{
  "id_token": {
    "acr": {
      "essential": true,
      "values":["possessionorinherence"]
    },
    "amr": {
      "essential": true,
      "values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
    }
  }
}

Declarações de id_token_hint padrão

Esta seção descreve o conteúdo necessário do token passado como id_token_hint na solicitação feita ao provedor. O token pode conter mais declarações do que a tabela a seguir mostra.

Para impedir que o token seja usado para qualquer outra coisa que não seja uma dica, ele é emitido no estado expirado. O token é assinado e pode ser verificado usando os metadados de descoberta da ID do Microsoft Entra publicados.

Declarações opcionais do Microsoft Entra ID

Se um provedor precisar de declarações opcionais da Microsoft Entra ID, você poderá configurar as seguintes declarações opcionais para id_token: given_name, family_name, preferred_username, upn. Para saber mais, confira Declarações opcionais.

Uso recomendado de declarações

Recomendamos que você associe contas no lado do provedor à conta no Azure usando as declarações oid e tid. Essas duas declarações têm a garantia de serem exclusivas para cada conta dentro do locatário.

Exemplo de id_token_hint

Aqui está um exemplo de id_token_hint um membro do diretório:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "Test User 2",
  "preferred_username": "testuser2@contoso.com"
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Aqui está um exemplo de id_token_hint de um usuário convidado no locatário:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536093790,
  "iat": 1536093791,
  "nbf": 1536093791,
  "name": "External Test User (Hotmail)",
  "preferred_username": "externaltestuser@hotmail.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
  }.

Ações sugeridas para provedores de identidade externa

Sugerimos que os provedores de identidade externos concluam os itens a seguir. A lista não está completa, e os provedores podem concluir outras etapas de validação se acharem necessário.

• Na solicitação:

  • Verifique se o redirect_uri foi publicado conforme descrito na chamada do Microsoft Entra ID para o provedor de identidade externo.
  • Verifique se a URL de descoberta configurada usa HTTPS e termina com /.well-known/openid-configuration. Além disso, verifique se ele não inclui parâmetros de consulta ou identificadores de fragmento. Verifique se o valor do emissor corresponde exatamente ao documento de descoberta.
  • Verifique se o client_id tem um valor atribuído ao Microsoft Entra ID, como ABCD.
  • O provedor deve primeiro validarid_token_hint apresentado a ele pelo Microsoft Entra ID.

• Das declarações em id_token_hint:

  • (Opcional) Faça uma chamada ao Microsoft Graph para buscar outros detalhes sobre esse usuário. As declarações oid e tid em id_token_hint são úteis nesse sentido. Para obter detalhes sobre as declarações fornecidas, id_token_hintconsulte Declarações padrãoid_token_hint.

• Execute qualquer outra atividade de autenticação para o produto do provedor.

• Dependendo do resultado das ações do usuário e de outros fatores, o provedor construirá e enviará uma resposta de volta à ID do Microsoft Entra, conforme explicado na próxima seção.

Processamento da resposta do provedor pelo Microsoft Entra ID

O provedor precisa usar POST para enviar uma resposta de volta para o redirect_uri. Os seguintes parâmetros devem ser fornecidos em uma resposta bem-sucedida:

Em caso de êxito, o provedor emitiria um valor id_token para o usuário. A ID do Microsoft Entra usa os metadados OIDC publicados para verificar se o token contém as declarações esperadas e realiza qualquer outra validação de token necessária pelo OIDC.

Declarações acr com suporte

Declarações amr com suporte

A ID do Microsoft Entra exige que a MFA esteja satisfeita em emitir um token com declarações de MFA. Portanto, somente métodos com um tipo diferente podem cumprir o requisito do segundo fator. Conforme mencionado anteriormente, os diferentes tipos de método que podem ser usados para cumprir o segundo fator são conhecimento, posse e inerência.

O Microsoft Entra ID valida o mapeamento de tipos com base na tabela a seguir.

Os IDs do Microsoft Entra consideram a Autenticação Multifator (MFA) satisfeita se nenhum problema for encontrado com o token e emitem um token para o usuário. Caso contrário, a solicitação do usuário falhará.

A falha é indicada pela emissão de parâmetros de resposta ao erro.

O Microsoft Entra ID considera a solicitação bem-sucedida se id_token parameter estiver presente na resposta e se o token for válido. Caso contrário, a solicitação é considerada malsucedida. A ID do Microsoft Entra falha na tentativa de autenticação original devido ao requisito da política de Acesso Condicional.

O Microsoft Entra ID abandona o estado da tentativa de autenticação cerca de 5 minutos após o redirecionamento para o provedor.

Tratamento de respostas de erro para Microsoft Entra ID

Os serviços do Microsoft Azure usam um correlationId valor para correlacionar chamadas em vários sistemas internos e externos. Ele serve como um identificador comum de toda a operação ou fluxo que potencialmente envolve várias chamadas HTTP. Quando ocorre um erro durante qualquer uma das operações, a resposta contém um campo chamado ID de Correlação.

Quando entrar em contato com o suporte da Microsoft ou um serviço semelhante, forneça o valor do ID de Correlação. Ele ajuda a acessar a telemetria e os logs mais rapidamente.

Por exemplo:

ENTRA IDSTS70002: Error validating credentials. ENTRA IDSTS50012: External ID token from issuer 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' failed signature verification. KeyID of token is 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u'

Trace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333

Correlation ID: aaaa0000-bb11-2222-33cc-444444dddddd

Timestamp: 2023-07-24 16:51:34Z

Controles personalizados e métodos de autenticação externa

Na ID do Microsoft Entra, os métodos de autenticação externa e os controles personalizados de Acesso Condicional podem operar em paralelo enquanto os clientes se preparam e migram para métodos de autenticação externos.

Os clientes que atualmente usam uma integração com um provedor externo por meio de controles personalizados podem continuar a usá-los, assim como as políticas de Acesso Condicional configuradas para gerenciar o acesso. Recomendamos que os administradores criem um conjunto paralelo de políticas de Acesso Condicional durante o período de migração:

• As políticas devem usar o controle de concessão Exigir autenticação multifator em vez de o controle personalizado.

  Observação

  Os controles de concessão com base nos pontos fortes de autenticação, incluindo a força interna da MFA, não são satisfeitos pelo método de autenticação externa. As políticas devem ser configuradas apenas com a opção Exigir autenticação multifator.

• A nova política pode ser testada primeiro com um subconjunto de usuários. O grupo de teste é excluído da política que requer controles personalizados e incluído na política que requer MFA. Quando o administrador estiver confortável de que a política que exige MFA seja atendida pelo método de autenticação externa, o administrador poderá incluir todos os usuários necessários na política com a concessão de MFA. A política configurada para controles personalizados pode ser movida para a configuração Desativada .

Suporte à integração

Se você tiver problemas ao criar a integração do método de autenticação externa com a ID do Microsoft Entra, o ISV (Fornecedor Independente de Soluções) da Microsoft CxE (Customer Experience Engineering) poderá ajudar. Para entrar em contato com a equipe de ISV do CxE, envie uma solicitação de assistência.

Referências

• Especificação OAuth2.0 e OIDC

Glossário

Conteúdo relacionado

• Para obter mais informações sobre como configurar um método de autenticação externa no Centro de administração do Microsoft Entra, consulte Gerenciar um método de autenticação externa na Microsoft (versão prévia).