Use o Microsoft Entra MFA com um fornecedor externo (pré-visualização)

Este artigo descreve como um fornecedor externo de autenticação se liga à autenticação multifatorial (MFA) Microsoft Entra.

Quando um usuário faz logon, 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.

Podem aplicar-se várias políticas ao início de sessão, dependendo dos seus parâmetros. Esses parâmetros incluem utilizadores e grupos, aplicações, a plataforma, o nível de risco de início de sessão e mais.

Com base nos requisitos de autenticação, o utilizador pode precisar de iniciar sessão com outro fator para cumprir o requisito de MFA. O tipo do segundo fator precisa de complementar o tipo do primeiro fator.

O administrador do tenant adiciona métodos de autenticação externos ao Microsoft Entra ID. Se um inquilino exigir um método de autenticação externo para MFA, o login é considerado cumprir o requisito de MFA após o Microsoft Entra ID validar ambos:

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

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

• Algo que você sabe (conhecimento)
• Algo que tu tens (posse)
• Algo que você é (inerência)

Métodos de autenticação externos são implementados por cima do OpenID Connect (OIDC). Esta implementação requer pelo menos três endpoints públicos para implementar um método de autenticação externo:

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

Eis como funciona o login com um método de autenticação externo:

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

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

3. O utilizador escolhe o método de autenticação externo como segundo fator.

4. O Microsoft Entra ID redireciona a sessão do navegador do utilizador para a URL do método de autenticação externo.

   Este URL é descoberto a partir do URL de descoberta que um administrador provisionou quando criou o método de autenticação externo.

   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 externo valida que o token veio do Microsoft Entra ID e verifica o conteúdo do token.

6. O fornecedor externo de autenticação pode fazer uma chamada ao Microsoft Graph para obter informações adicionais sobre o utilizador.

7. O fornecedor externo de autenticação realiza quaisquer ações que considere necessárias, como autenticar o utilizador com uma credencial.

8. O fornecedor externo de autenticação redireciona o utilizador de volta para o ID Microsoft Entra com um token válido, incluindo todas as reivindicações necessárias.

9. O Microsoft Entra ID valida que a assinatura do token veio do provedor de autenticação externo configurado e, em seguida, 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 utilizador cumpriu o requisito de MFA. O usuário também pode ter que atender a outros requisitos de política.

Configuração de um novo fornecedor externo de autenticação com o Microsoft Entra ID

Para emitir id_token_hint, métodos externos de autenticação precisam de uma aplicação que represente a integração. Pode criar a aplicação de duas formas:

• Em cada inquilino que utiliza o fornecedor externo.
• Como uma única aplicação multiinquilino. Para permitir a integração para o inquilinato, os administradores de funções privilegiadas precisam conceder consentimento.

A utilização de uma aplicação multitenant pode reduzir o risco de configuração incorreta em cada entidade. Os fornecedores também podem fazer alterações aos metadados (por exemplo, URLs de resposta num só local), em vez de exigir que cada inquilino faça as alterações.

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

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

2. Registe uma aplicação no respetivo locatário.

3. Na aplicação, em Tipos de Conta Suportados, selecione Contas em qualquer diretório organizacional (Qualquer locatário Microsoft Entra ID - Multilocação).

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

5. Não publique nenhum escopo nesta aplicação.

6. Adicione os URLs válidos authorization_endpoint do provedor de identidade externo àquela aplicação como URLs de resposta.

   Nota

   No registo da aplicação, adicione o authorization_endpoint valor fornecido no documento de descoberta do fornecedor como URL de redirecionamento. Caso contrário, recebe o seguinte erro: "ENTRA IDSTS50161: Falhou a validação do URL de autorização do fornecedor externo de reclamações!"

O processo de registro do aplicativo cria um aplicativo com várias propriedades. Precisas destas propriedades para o nosso cenário.

Outro modelo válido para suportar integração é usar uma aplicação para cada inquilino. Se utilizar um registo de inquilino único, o administrador do inquilino deve criar um registo de aplicação com as propriedades indicadas na tabela anterior para uma aplicação de inquilino único.

Configurar afirmações opcionais

Um fornecedor pode configurar mais declarações utilizando declarações opcionais para id_token.

Adicionar um método de autenticação externo ao Microsoft Entra ID

A informação do fornecedor de identidade externa é armazenada na política de métodos de autenticação de cada inquilino. A informação do fornecedor é armazenada como um método de autenticação do tipo externalAuthenticationMethodConfiguration.

Cada provedor tem uma entrada no objeto de lista da política. Cada entrada deve indicar:

• Se o método estiver ativado.
• 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 o login do utilizador, os utilizadores com o papel de Administrador de Acesso Condicional podem criar uma política com a concessão Exigir MFA. Atualmente, não há suporte para métodos de autenticação externos com pontos fortes de autenticação.

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

Interação do Microsoft Entra ID com o provedor

As secções seguintes explicam os requisitos dos fornecedores e incluem exemplos de como o Microsoft Entra ID interage com um fornecedor.

Descoberta de metadados do provedor

Um provedor de identidade externo precisa fornecer um endpoint de descoberta OIDC. Este ponto de extremidade é 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. Não podes incluir segmentos de caminho, sequências de consulta ou fragmentos adicionais depois deste segmento. A URL de descoberta completa deve ser incluída na URL de descoberta que configura quando cria o método de autenticação externo.

O endpoint devolve um documento JSON de metadados do fornecedor alojado aí. O endpoint deve também devolver um cabeçalho válido de comprimento de conteúdo. O documento de metadados deve estar em conformidade com o OpenID Connect Discovery 1.0 (incorporando o errata set 2) e incluir todos os campos de metadados OIDC obrigatórios.

Os metadados do fornecedor devem incluir os dados listados na tabela seguinte. Esses valores são necessários para esse cenário de extensibilidade. O documento de metadados JSON pode conter mais informação.

Para o documento OIDC que contém os valores dos metadados do fornecedor, veja Metadados do Fornecedor.

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 emissores

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

URL de descoberta válida e pares de emissores

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

Exemplo de URL de descoberta inválida e exemplos de emissores

• 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 portas.)
• URL de descoberta: https://example.com/.well-known/openid-configuration?client_id=0oasxuxkghOniBjlQ697
  Emissor: https://example.com (Não pode incluir uma cadeia de consulta numa URL de descoberta.)

Cache de metadados do provedor

Para melhorar o desempenho, o Microsoft Entra ID armazena em cache os metadados que o fornecedor devolve, incluindo as chaves. A cache de metadados do fornecedor impede uma chamada de descoberta sempre que o Microsoft Entra ID comunica com um fornecedor externo de identidade.

Esta cache é atualizada a cada 24 horas. Recomendamos que os prestadores sigam estes passos para transferir as suas chaves:

1. Publique o Certificado Existente e o Novo Certificado em jwks_uri.
2. Continue a fazer login com o Certificado Existente até que a cache do Microsoft Entra ID seja atualizada, expirada ou renovada (a cada 2 dias).
3. Mude para iniciar sessão com o Novo Certificado.

Não publicamos cronogramas para renovações de chaves. O serviço dependente deve estar preparado para lidar com transferências imediatas e periódicas. Sugerimos usar uma biblioteca dedicada construída para este propósito, como azure-activedirectory-identitymodel-extensions-for-dotnet. Para obter mais informações, consulte Rollover da chave de assinatura na Identidade do Microsoft Entra.

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 finais de descoberta de 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

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

Validando tokens emitidos pelo Microsoft Entra ID

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

Pode encontrar todos os detalhes sobre validação de tokens na biblioteca de validação de tokens da Microsoft. Também pode apurar estes detalhes navegando pelo código-fonte. Para obter um exemplo, consulte Exemplos do Azure.

Depois de a validação ser bem-sucedida, pode trabalhar com a carga de sinistros para obter detalhes sobre o utilizador e o seu inquilino.

Chamada do Microsoft Entra ID para o fornecedor de identidade externo

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

Para informar o fornecedor sobre o utilizador para quem o Microsoft Entra ID está a fazer o pedido, o Microsoft Entra ID passa um token através do id_token_hint parâmetro.

Esta chamada é feita através de um POST pedido porque uma grande lista de parâmetros é passada ao fornecedor. Uma lista grande impede o uso de navegadores que limitam o comprimento de um GET pedido.

Os parâmetros do pedido de autenticação estão listados na tabela seguinte.

Exemplo de um URI de redirecionamento

Os URIs de redirecionamento devem ser registados com o fornecedor fora da banda. Os URIs de redirecionamento que 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 externo que satisfaz a MFA

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

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

• O método de autenticação usado para o segundo fator satisfaz o requisito MFA.
• O método de autenticação é de um tipo diferente do método utilizado para completar o primeiro fator de início de sessão 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 predefinidas de id_token_hint

Esta secção descreve o conteúdo necessário do token que é passado como id_token_hint no pedido feito ao fornecedor. O token pode conter mais reivindicações do que a tabela seguinte mostra.

Para evitar que o token seja usado para algo que não seja uma pista, é emitido no estado expirado. O token é assinado e pode ser verificado utilizando os metadados de descoberta do ID Microsoft Entra publicados.

Declarações opcionais do Microsoft Entra ID

Se um fornecedor precisar de pedidos opcionais do Microsoft Entra ID, pode configurar os seguintes pedidos opcionais para id_token: given_name, family_name, preferred_username, upn. Para obter mais informações, consulte Declarações opcionais.

Utilização recomendada de alegações

Recomendamos que associe as contas do lado do fornecedor à conta no Azure usando as reivindicações oid e tid. Estas duas declarações são garantidas como únicas para a conta no locatário.

Exemplo de id_token_hint

Aqui está um exemplo de id_token_hint para 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 para um utilizador convidado no tenant:

{
  "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 externos

Sugerimos que os fornecedores externos de identidade preencham os seguintes pontos. A lista não é exaustiva e os fornecedores devem concluir outras etapas de validação como acharem melhor.

• A partir do pedido:

  • Certifique-se de que o redirect_uri está publicado conforme descrito na requisição Microsoft Entra ID ao fornecedor externo de identidade.
  • Certifique-se de que a URL de descoberta configurada usa HTTPS e termina em /.well-known/openid-configuration. Assegura-te também de que não inclui parâmetros de consulta ou identificadores de fragmentos. Certifique-se de que o valor do emissor corresponde exatamente ao documento de descoberta.
  • Certifique-se de que o client_id tem um valor atribuído ao ID Microsoft Entra, como ABCD.
  • O fornecedor deve primeiro validar o id_token_hint que o Microsoft Entra ID lhe apresenta.

• Das reivindicações no id_token_hint:

  • (Opcional) Ligue para o Microsoft Graph para obter outros detalhes sobre este utilizador. As reivindicações oid e tid em id_token_hint são úteis neste sentido. Para obter detalhes sobre as declarações fornecidas em id_token_hint, consulte Declarações padrãoid_token_hint.

• Realize qualquer outra atividade de autenticação para o produto do fornecedor.

• Dependendo do resultado das ações do utilizador e de outros fatores, o fornecedor então construiria e enviaria uma resposta para o ID Microsoft Entra, conforme explicado na secção seguinte.

Processamento da resposta do fornecedor pelo Microsoft Entra ID

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

Em caso de sucesso, o fornecedor emitiria então um valor id_token para o utilizador. O Microsoft Entra ID utiliza os metadados OIDC publicados para verificar se o token contém as reivindicações esperadas e realiza qualquer outra validação de token que o OIDC exiga.

Reivindicações suportadas de ACR

Declarações AMR suportadas

O Microsoft Entra ID exige que a MFA esteja satisfeita ao emitir um token com reivindicações MFA. Como resultado, apenas métodos com um tipo diferente podem satisfazer o segundo requisito de fator. Como mencionado anteriormente, os diferentes tipos de método que podem ser usados para satisfazer o segundo fator são conhecimento, posse e inerência.

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

O Microsoft Entra ID considera que a MFA está satisfeita se não forem encontrados problemas com o token, e emite um token ao utilizador. Caso contrário, o pedido do utilizador falha.

A falha é indicada pela emissão de parâmetros de resposta a erros.

O Microsoft Entra ID considera o pedido bem-sucedido se id_token parameter estiver presente na resposta e se o token for válido. Caso contrário, o pedido é considerado infrutífero. O Microsoft Entra ID falha na tentativa original de autenticação devido à exigência da política de Acesso Condicional.

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

Gestão de respostas de erro no Microsoft Entra ID

Os serviços Microsoft Azure usam um correlationId valor para correlacionar chamadas entre 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 Correlação ID.

Quando contactar o suporte da Microsoft ou um serviço semelhante, forneça o ID de Correlação. Ajuda a aceder à telemetria e aos registos 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

Controlos personalizados e métodos externos de autenticação

No Microsoft Entra ID, métodos de autenticação externos e controlos 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 usando controles personalizados podem continuar a usá-los e quaisquer políticas de Acesso Condicional que eles configuraram 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 do controle de concessão personalizado.

  Nota

  Os controles de atribuição baseados em níveis de autenticação, incluindo o nível de MFA incorporado, não são atendidos pelo método de autenticação externo. As políticas só devem ser configuradas com Exigir autenticação multifator.

• A nova política pode ser testada primeiro com um subconjunto de usuários. O grupo de teste está excluído da política que exige controlos personalizados e está incluído na política que exige Autenticação Multifator (MFA). Quando o administrador está confiante de que a política que exige MFA está satisfeita pelo método de autenticação externo, o administrador pode incluir todos os utilizadores necessários na política com a atribuição de MFA. A política configurada para controlos personalizados pode ser movida para a definição Desligado .

Suporte à integração

Se tiver algum problema ao construir integração de métodos de autenticação externos com o Microsoft Entra ID, o fornecedor independente de soluções (ISV) da Microsoft Customer Experience Engineering (CxE) poderá ajudar. Para interagir com a equipe CxE ISV, envie uma solicitação de assistência.

Referências

• Especificação OAuth2.0 e OIDC

Glossário

Conteúdo relacionado

• Para mais informações sobre como configurar um método de autenticação externo no centro de administração do Microsoft Entra, consulte Gerenciar um método de autenticação externo na Microsoft (Pré-visualização).