Referencia del proveedor de métodos externos de autenticación multifactor de Microsoft Entra (versión preliminar)

En este tema se describe cómo un proveedor de autenticación externo se conecta a la autenticación multifactor (MFA) de Microsoft Entra. Un proveedor de autenticación externo puede integrarse con los inquilinos de Microsoft Entra ID como un método de autenticación externo (EAM). Un EAM puede satisfacer el segundo factor de un requisito de MFA para el acceso a un recurso o aplicación. EAM requiere al menos una licencia Microsoft Entra ID P1.

Cuando un usuario inicia sesión, se evalúan las directivas de inquilino. Los requisitos de autenticación se determinan en función del recurso al que el usuario intenta acceder.

Se pueden aplicar varias directivas al inicio de sesión, en función de sus parámetros. Estos parámetros incluyen usuarios y grupos, aplicaciones, plataforma, nivel de riesgo de inicio de sesión, etc.

En función de los requisitos de autenticación, es posible que el usuario tenga que iniciar sesión con otro factor para cumplir el requisito de MFA. El segundo factor debe complementar el tipo de primer factor.

El administrador de inquilinos agrega los EAM al identificador de Microsoft Entra. Si un inquilino requiere un EAM para MFA, el inicio de sesión se considera que cumple el requisito de MFA después de que Microsoft Entra ID valide ambos:

• El primer factor completado con el identificador de Entra de Microsoft
• El segundo factor completado con el EAM

Esa validación cumple el requisito de MFA para dos o más tipos de métodos de:

• Algo que sabes (conocimiento)
• Algo que tienes (posesión)
• Algo que eres (inherencia)

Los EAM se implementan sobre Open ID Connect (OIDC). Esta implementación requiere al menos tres puntos de conexión accesibles públicamente:

• Un punto de conexión de detección de OIDC, tal como se describe en Detección de metadatos del proveedor
• Un punto de conexión de autenticación OIDC válido
• Dirección URL en la que se publican los certificados públicos del proveedor

Veamos más detenidamente cómo funciona el inicio de sesión con un EAM:

1. Un usuario intenta iniciar sesión con un primer factor, como una contraseña, en una aplicación protegida por el identificador de Entra de Microsoft.
2. Microsoft Entra ID determina que debe cumplirse otro factor. Por ejemplo, una directiva de acceso condicional requiere MFA.
3. El usuario elige el EAM como segundo factor.
4. Microsoft Entra ID redirige la sesión del explorador del usuario a la dirección URL de EAM:
   1. Esta dirección URL se detecta a partir de la dirección URL de detección aprovisionada por un administrador cuando creó el EAM.
   2. La aplicación proporciona un token expirado o casi expirado que contiene información para identificar al usuario y al inquilino.
5. El proveedor de autenticación externo valida que el token procede de Microsoft Entra ID y comprueba el contenido del token.
6. El proveedor de autenticación externa puede realizar opcionalmente una llamada a Microsoft Graph para capturar información adicional sobre el usuario.
7. El proveedor de autenticación externa realiza cualquier acción que considere necesaria, como autenticar al usuario con alguna credencial.
8. El proveedor de autenticación externa redirige al usuario a Microsoft Entra ID con un token válido, incluidas todas las notificaciones necesarias.
9. Microsoft Entra ID valida que la firma del token procede del proveedor de autenticación externo configurado y, a continuación, comprueba el contenido del token.
10. Microsoft Entra ID valida el token con respecto a los requisitos.
11. El usuario cumplió el requisito de MFA si la validación se realiza correctamente. Es posible que el usuario también tenga que cumplir otros requisitos de directiva.

Configuración de un nuevo proveedor de autenticación externa con el identificador de Microsoft Entra

Se requiere una aplicación que represente la integración para que los EAM emitan el id_token_hint. La aplicación se puede crear de dos maneras:

• Creado en cada inquilino que usa el proveedor externo.
• Se crea como una aplicación multiinquilino. Los administradores de roles con privilegios deben conceder consentimiento para habilitar la integración para su inquilino.

Una aplicación multiinquilino reduce la posibilidad de una configuración incorrecta en cada inquilino. También permite a los proveedores realizar cambios en metadatos como direcciones URL de respuesta en un solo lugar, en lugar de requerir que cada inquilino realice los cambios.

Para configurar una aplicación multiinquilino, el administrador del proveedor debe:

1. Cree un inquilino de Id. de Microsoft Entra si aún no tiene uno.

2. Registre una aplicación en su inquilino.

3. Establezca los tipos de cuenta admitidos de la aplicación en: Cuentas de cualquier directorio organizativo (cualquier inquilino de Id. de Microsoft Entra: multiinquilino).

4. Agregue los permisos delegados openid y profile del perfil de Microsoft Graph a la aplicación.

5. No publique ningún ámbito en esta aplicación.

6. Agregue las direcciones URL válidas del proveedor de identidades externos authorization_endpoint a esa aplicación como direcciones URL de respuesta.

   Nota:

   El authorization_endpoint proporcionado en el documento de detección del proveedor debe agregarse como dirección URL de redireccionamiento en el registro de la aplicación. De lo contrario, obtendrá el siguiente error: ENTRA IDSTS50161: No se pudo validar la dirección URL de autorización del proveedor de notificaciones externos

El proceso de registro de aplicaciones crea una aplicación con varias propiedades. Estas propiedades son necesarias para nuestro escenario.

Una aplicación para cada inquilino también es un modelo válido para admitir la integración. Si usa un registro de inquilino único, el administrador de inquilinos debe crear un registro de aplicación con las propiedades de la tabla anterior para una aplicación de un solo inquilino.

Configuración de notificaciones opcionales

Un proveedor puede configurar más notificaciones mediante notificaciones opcionales para id_token.

Adición de un identificador de EAM a Microsoft Entra

La información del proveedor de identidades externo se almacena en la directiva de métodos de autenticación de cada inquilino. La información del proveedor se almacena como un método de autenticación de tipo externalAuthenticationMethodConfiguration.

Cada proveedor tiene una entrada en el objeto de lista de la directiva. Cada entrada debe indicar:

• Si el método está habilitado
• Los grupos incluidos que pueden usar el método
• Los grupos excluidos que no pueden usar el método

Los administradores de acceso condicional pueden crear una directiva con la concesión requerir MFA para establecer el requisito de MFA para el inicio de sesión de usuario. Actualmente no se admiten métodos de autenticación externos con puntos fuertes de autenticación.

Para obtener más información sobre cómo agregar un método de autenticación externo en el Centro de administración de Microsoft Entra, consulte Administrar un método de autenticación externo en Microsoft Entra ID (versión preliminar).

Interacción del identificador de Entra de Microsoft con el proveedor

En las secciones siguientes se explican los requisitos del proveedor e incluyen ejemplos para la interacción del identificador de Entra de Microsoft con un proveedor.

Detección de metadatos del proveedor

Un proveedor de identidades externo debe proporcionar un punto de conexiónde detección de OIDC. Este punto de conexión se usa para obtener más datos de configuración. Dirección URL completa, incluida .oidc-configuration/conocido, debe incluirse en la dirección URL de detección configurada cuando se crea el EAM.

El punto de conexión devuelve un documento JSON de metadatos del proveedor hospedado allí. El punto de conexión también debe devolver el encabezado de longitud de contenido válido.

En la tabla siguiente se enumeran los datos que deben estar presentes en los metadatos del proveedor. Estos valores son necesarios para este escenario de extensibilidad. El documento de metadatos JSON puede contener más información.

Para el documento OIDC con los valores de Metadatos del proveedor, consulte Metadatos del proveedor.

http://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",
  "jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
  "response_modes_supported": [
    "form_post"
  ],
  "response_types_supported": [
    "id_token"
  ],
  "scopes_supported": [
    "openid"
  ],
  "SigningKeys": [],
  "subject_types_supported": [
    "public"
  ]
}

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

Almacenamiento en caché de metadatos del proveedor

Para mejorar el rendimiento, el proveedor almacena en caché los metadatos de Microsoft Entra ID devueltos por el proveedor, incluidas las claves. El almacenamiento en caché de metadatos del proveedor impide una llamada de detección cada vez que Microsoft Entra ID se comunica con un proveedor de identidades externo.

Esta caché se actualiza cada 24 horas (un día). Este es el modo en que se recomienda que un proveedor reversión de sus claves:

1. Publique el certificado existente y el nuevo certificado en "jwks_uri".
2. Siga firmando con el certificado existente hasta que se actualice, expire o actualice la memoria caché del identificador de Entra de Microsoft (cada 2 días).
3. Cambie a firma con Nuevo certificado.

No publicamos programaciones para las sustituciones de claves. El servicio dependiente debe estar preparado para controlar las reversiones inmediatas y periódicas. Se recomienda usar una biblioteca dedicada creada para este propósito, como azure-activedirectory-identitymodel-extensions-for-dotnet. Para obtener más información, consulte Sustitución de claves de firma en Microsoft Entra ID.

Detección de metadatos de Id. de Microsoft Entra

Los proveedores también deben recuperar las claves públicas de Id. de Microsoft Entra para validar los tokens emitidos por el identificador de Microsoft Entra.

Puntos de conexión de detección de metadatos de Microsoft Entra ID:

• Global Azure: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
• Azure para la Administración Pública de Estados Unidos: https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration
• Microsoft Azure operado por 21Vianet: https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration

Con el identificador de clave pública del token (el "niño" de la firma web JSON (JWS)), se puede determinar cuál de las claves recuperadas de la propiedad jwks_uri debe usarse para validar la firma del token de id. de Microsoft Entra.

Validación de tokens emitidos por el identificador de Entra de Microsoft

Para obtener información sobre cómo validar los tokens emitidos por Microsoft Entra ID, consulte Validación y token de identificador. No hay pasos especiales para los consumidores de nuestros metadatos de detección.

La biblioteca de validación de tokens de Microsoft tiene todos los detalles sobre los detalles de la validación de tokens que se documentan o se pueden determinar al examinar el código fuente. Para ver un ejemplo, consulte Ejemplos de Azure.

Una vez que la validación se realiza correctamente, puede trabajar con la carga de notificaciones para obtener detalles del usuario y su inquilino.

Llamada de Id. de Microsoft Entra al proveedor de identidades externo

Microsoft Entra ID usa el flujo implícito de OIDC para comunicarse con el proveedor de identidades externo. Con este flujo, la comunicación con el proveedor se realiza exclusivamente mediante el punto de conexión de autorización del proveedor. Para informar al proveedor del usuario para el que Microsoft Entra ID realiza la solicitud, el identificador de Microsoft Entra pasa un token a través del parámetro id_token_hint.

Esta llamada se realiza a través de una solicitud POST porque la lista de parámetros pasados al proveedor es grande. Una lista grande impide el uso de exploradores que limitan la longitud de una solicitud GET.

Los parámetros de solicitud de autenticación se enumeran en la tabla siguiente.

Ejemplo de un URI de redirección

Los identificadores uniformes de recursos (URI) de redirección deben registrarse con el proveedor fuera de banda. Los URI de redireccionamiento que se pueden enviar son:

• Azure Global: https://login.microsoftonline.com/common/federation/externalauthprovider
• Azure para la Administración Pública de Estados Unidos: https://login.microsoftonline.us/common/federation/externalauthprovider
• Microsoft Azure operado por 21Vianet: https://login.partner.microsoftonline.cn/common/federation/externalauthprovider

Ejemplo de un EAM que satisface MFA

Este es un ejemplo de una autenticación en la que EAM satisface MFA. Este ejemplo ayuda a un proveedor a saber qué notificaciones espera Microsoft Entra ID.

Microsoft Entra ID usa la combinación de los valores acr y amr para validar:

• El método de autenticación usado para el segundo factor satisface el requisito de MFA
• El método de autenticación difiere en "type" del método usado para completar el primer factor para el inicio de sesión en 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"]
    }
  }
}

Notificaciones de Id_token_hint predeterminadas

En esta sección se describe el contenido necesario del token pasado como id_token_hint en la solicitud realizada al proveedor. El token puede contener más notificaciones que en la tabla siguiente.

Para evitar que se use para algo distinto de una sugerencia, el token se emite como expirado. El token está firmado y se puede comprobar mediante los metadatos de detección de identificadores de Microsoft Entra publicados.

Notificaciones opcionales de Microsoft Entra ID

Si un proveedor necesita notificaciones opcionales de Microsoft Entra ID, puede configurar estas notificaciones opcionales para id_token. Para obtener más información, consulte Conjunto de notificaciones opcionales.

Uso recomendado de notificaciones

Microsoft recomienda asociar cuentas en el lado del proveedor con la cuenta de Azure AD mediante las notificaciones oid y tid. Se garantiza que estas dos notificaciones son únicas para la cuenta en el inquilino.

Ejemplo de un id_token_hint

Este es un ejemplo de un id_token_hint para un miembro de directorio:

{
  "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"
  }.

Este es un ejemplo de la sugerencia de id_token para un usuario invitado en el inquilino:

{
  "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"
  }.

Acciones sugeridas para proveedores de identidades externos

Se recomienda que los proveedores de identidades externos completen estos pasos. La lista no es exhaustiva y los proveedores deben completar otros pasos de validación a medida que se ajusten.

1. Desde la solicitud:
   • Asegúrese de que el redirect_uri se publica en la llamada id. de Microsoft Entra al proveedor de identidades externo.
   • Asegúrese de que el client_id tiene un valor asignado a Microsoft Entra ID, como ABCD.
   • El proveedor debe validar primero el id_token_hint que le presenta Microsoft Entra ID.
2. Desde las notificaciones del id_token_hint:
   • Opcionalmente, pueden realizar una llamada a Microsoft Graph para capturar otros detalles sobre este usuario. Las notificaciones oid y tid en el id_token_hint son útiles en este sentido. Para obtener más información sobre las notificaciones proporcionadas en el id_token_hint, consulte Notificaciones de id_token_hint predeterminadas.
3. A continuación, lleve a cabo cualquier otra actividad de autenticación que se cree para el producto del proveedor.
4. Según el resultado de las acciones del usuario y otros factores, el proveedor construiría y enviaría una respuesta de nuevo a Microsoft Entra ID, como se explica en la sección siguiente.

Procesamiento del identificador de Entra de Microsoft de la respuesta del proveedor

El proveedor debe volver a ENVIAR una respuesta al redirect_uri. Se deben proporcionar los parámetros siguientes en una respuesta correcta:

Si se ejecuta correctamente, el proveedor emitiría un id_token para el usuario. Microsoft Entra ID usa los metadatos de OIDC publicados para comprobar que el token contiene las notificaciones esperadas y realiza cualquier otra validación del token que requiere OIDC.

Notificaciones acr admitidas

Notificaciones de amr admitidas

Microsoft Entra ID requiere que MFA esté satisfecho para emitir un token con notificaciones de MFA. Como resultado, solo los métodos con un tipo diferente pueden satisfacer el requisito de segundo factor. Como se mencionó anteriormente, los diferentes tipos de método que se pueden usar para satisfacer el segundo factor son conocimiento, posesión e inherencia.

Microsoft Entra ID valida la asignación de tipos en función de la tabla siguiente.

Si no se encuentra ningún problema con el token, Microsoft Entra ID considera que MFA está satisfecho y emite un token al usuario final. De lo contrario, se produce un error en la solicitud del usuario final.

El error se indica mediante la emisión de parámetros de respuesta de error.

Microsoft Entra ID considera que la solicitud se realiza correctamente si el parámetro id_token está presente en la respuesta y si el token es válido. De lo contrario, la solicitud se considera incorrecta. Microsoft Entra ID produce un error en el intento de autenticación original debido al requisito de la directiva de acceso condicional.

Microsoft Entra ID abandona el estado del intento de autenticación a finales de unos 10 minutos después de la redirección al proveedor.

Control de respuestas de errores de Id. de Microsoft Entra

Los servicios de Microsoft Azure usan un correlationId para correlacionar las llamadas entre varios sistemas internos y externos. Actúa como un identificador común de toda la operación o flujo que potencialmente implica varias llamadas HTTP. Cuando se produce un error durante cualquiera de las operaciones, la respuesta contiene un campo denominado Id. de correlación.

Cuando llegue al soporte técnico de Microsoft o a un servicio similar, proporcione el valor de este identificador de correlación, ya que ayuda a acceder a la telemetría y los registros más rápidos.

Por ejemplo:

ENTRA IDSTS70002: error al validar las credenciales. ENTRA IDSTS50012: El token de identificación externo del emisor 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' falló la verificación de la firma. El token de KeyID es 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' Id. de seguimiento: 0000aaaa-11bb-cccc-dd22-eeeeee333333 Id. de correlación: aaaa0000-bb11-2222-33cc-444444dddddd Marca de tiempo: 2023-07-24 16:51:34Z

Controles personalizados y EAM

En Microsoft Entra ID, los EAM y los controles personalizados de acceso condicional pueden funcionar en paralelo mientras los clientes están preparados para migrar y migrar a EAM.

Los clientes que actualmente usan una integración con un proveedor externo mediante controles personalizados pueden seguir usándolas y las directivas de acceso condicional configuradas para administrar el acceso. Se recomienda a los administradores crear un conjunto paralelo de directivas de acceso condicional durante el período de migración:

• Las directivas deben usar la concesión de control Requerir autenticación multifactor en lugar de la concesión de control personalizado.

  Nota:

  La EAM no satisface los controles basados en los puntos fuertes de autenticación, incluido el nivel de MFA integrado. Las directivas solo deben configurarse con Requerir autenticaciónmultifactor. Estamos trabajando activamente para admitir EAM con puntos fuertes de autenticación.

• La nueva directiva se puede probar primero con un subconjunto de usuarios. El grupo de pruebas se excluiría de la directiva que requiere los controles personalizados e incluirse en la directiva que requiere MFA. Una vez que el administrador esté seguro de que la política que requiere MFA es satisfecha por el EAM, puede incluir a todos los usuarios requeridos en la política con la concesión de MFA, y la política configurada para controles personalizados puede pasar a Desactivado.

Compatibilidad con la integración

Si tiene algún problema al compilar la integración de EAM con microsoft Entra ID, es posible que el proveedor de soluciones independientes (ISV) de Ingeniería de experiencia del cliente de Microsoft (CxE) pueda ayudar. Para interactuar con el equipo de ISV de CxE, envíe una solicitud de ayuda.

Referencias

• Especificación de OAuth2.0 y OIDC

Glosario

Pasos siguientes

Para obtener más información sobre cómo configurar un EAM en el Centrode administración de Microsoft Entra, consulte Administrar un método de autenticación externo en Microsoft (versión preliminar).