Patrón de Identidad Federada

Delegar la autenticación de usuario en un proveedor de identidades externo (IdP) para simplificar el desarrollo, minimizar las tareas administrativas y mejorar la experiencia de usuario de la aplicación.

Contexto y problema

Normalmente, los usuarios necesitan trabajar con varias aplicaciones que las organizaciones asociadas proporcionan y hospedan. Es posible que necesiten usar credenciales de inicio de sesión específicas y diferentes para cada aplicación. Este requisito puede:

• Provocar una experiencia de usuario inconexa. Los empleados suelen olvidar varias credenciales de inicio de sesión.

• Exponer vulnerabilidades de seguridad. Cuando un empleado abandona la empresa, la organización debe desactivar inmediatamente la cuenta. A menudo, las organizaciones grandes pierden este paso crítico.

• Complica la administración de usuarios. Los administradores administran las credenciales de usuario, emiten recordatorios de contraseña y realizan otras tareas administrativas.

Normalmente, los usuarios prefieren usar las mismas credenciales de inicio de sesión para todas las aplicaciones.

Solución

Implemente un mecanismo de autenticación de identidad federada. Separar la autenticación de usuario del código de aplicación y delegar la autenticación en un IdP de confianza. Este proceso simplifica el desarrollo, minimiza la carga administrativa y proporciona la autenticación de usuarios a través de diversos IdP. La identidad federada también separa la autenticación de la autorización.

Los IdP de confianza incluyen directorios corporativos, servicios de federación locales, servicios de tokens de seguridad (STS) e IdP sociales como Microsoft, Google, Yahoo! o Facebook.

En el diagrama siguiente se muestra el patrón de identidad federada para una aplicación cliente que tiene acceso a un servicio que requiere autenticación. El IdP funciona con un STS para proporcionar autenticación. El IdP emite tokens de seguridad que proporcionan información sobre el usuario autenticado. Esta información, denominada notificaciones, incluye la identidad del usuario y también puede incluir otras notificaciones, como pertenencias a roles y derechos de acceso más granulares.

Este modelo también se denomina control de acceso basado en notificaciones. Las aplicaciones y los servicios autorizan el acceso a las características y la funcionalidad en función de las declaraciones. El servicio que requiere autenticación debe confiar en el IdP. La aplicación cliente se pone en contacto con el IdP para la autenticación. Si la autenticación se realiza correctamente, el IdP devuelve un token que contiene declaraciones que identifican al usuario para el STS. El IdP y el STS pueden formar parte del mismo servicio. El STS puede transformar y ampliar las declaraciones según reglas predefinidas antes de devolver el token al cliente. A continuación, la aplicación cliente pasa este token al servicio como prueba de su identidad.

La autenticación federada proporciona un método basado en estándares para establecer la confianza en identidades entre dominios y admite el inicio de sesión único (SSO). Muchas aplicaciones, especialmente las aplicaciones hospedadas en la nube, usan la autenticación federada porque admite el inicio de sesión único sin una conexión de red directa a un IdP. Este diseño aumenta la seguridad, ya que el usuario no necesita crear y escribir credenciales de inicio de sesión diferentes para varias aplicaciones. También limita la exposición de credenciales únicamente al IdP original. Las aplicaciones solo ven la información de identidad autenticada en el token.

Las aplicaciones y los servicios que usan la autenticación federada no necesitan proporcionar características de administración de identidades. En su lugar, el IdP es responsable de la administración de identidades y credenciales. Cuando el directorio corporativo confía en el IdP, no es necesario administrar la identidad del usuario. Este enfoque elimina la sobrecarga administrativa de la administración de identidades de usuario basada en directorios.

Problemas y consideraciones

Tenga en cuenta los puntos siguientes al decidir cómo implementar este patrón:

• La autenticación puede ser un único punto de error. Para mantener la confiabilidad y la disponibilidad de las aplicaciones en varias regiones, considere la posibilidad de implementar el mecanismo de administración de identidades en las mismas regiones que la aplicación.

• Para configurar el control de acceso basado en rol (RBAC), use herramientas de autenticación. RBAC admite un control pormenorizado sobre el acceso a características y recursos.

• A diferencia de un directorio corporativo, la autenticación basada en notificaciones de identidad que utiliza proveedores de identidad sociales (IdP) suele proporcionar únicamente la dirección de correo electrónico del usuario autenticado y, a veces, su nombre. Algunos idP sociales, como Microsoft, solo proporcionan un identificador único. Normalmente, la aplicación mantiene determinada información sobre los usuarios registrados para poder relacionarla con el identificador de las declaraciones. Esta tarea se completa normalmente durante el registro, cuando el usuario accede por primera vez a la aplicación. A continuación, la información se incorpora al token como nuevas claims después de cada autenticación.

• Si se configuran varios IDP para el STS, el STS debe determinar qué IdP debe autenticar al usuario. Este proceso se denomina detección del dominio de origen. El STS puede determinar el IdP automáticamente en función de la información proporcionada por el usuario, como una dirección de correo electrónico o un nombre de usuario, el subdominio de la aplicación, el intervalo de direcciones IP del usuario o una cookie almacenada en el explorador del usuario. Por ejemplo, si el usuario escribe una dirección de correo electrónico de Microsoft, como user@live.com, el STS redirige al usuario a la página de inicio de sesión de cuenta Microsoft. En las visitas posteriores, el STS puede usar una cookie que indique que el usuario ha iniciado sesión previamente mediante un cuenta Microsoft. Si el STS no puede determinar automáticamente el dominio principal, muestra una página de detección del dominio de inicio que muestra los IDP de confianza. Después, el usuario selecciona un IdP.

Cuándo usar este patrón

Use este patrón cuando necesite:

• SSO en la empresa. En este escenario, debe autenticar a los empleados para las aplicaciones corporativas hospedadas en la nube fuera del límite de seguridad corporativa, sin necesidad de iniciar sesión cada vez que visitan una aplicación. La experiencia del usuario coincide con las aplicaciones locales. Los usuarios se autentican cuando inician sesión en la red corporativa y, a continuación, pueden acceder a las aplicaciones pertinentes sin otro inicio de sesión.

• Identidad federada con varios asociados. En este escenario, debe autenticar a empleados corporativos y asociados comerciales que no tengan cuentas en el directorio corporativo. Esta práctica es común en aplicaciones empresariales, aplicaciones que se integran con los servicios de asociados y en empresas que usan diferentes sistemas de TI, o recursos combinados o compartidos.

• Identidad federada en aplicaciones de software como servicio (SaaS). En este escenario, los proveedores de software independientes proporcionan un servicio listo para usar para varios clientes o inquilinos. Los inquilinos se autentican mediante un IdP adecuado. Por ejemplo, los usuarios empresariales usan sus credenciales corporativas, mientras que los consumidores de inquilinos y los clientes usan credenciales de identidad social.

• Identidad federada para el acceso a cargas de trabajo. En este escenario, las aplicaciones de arrendatario, los flujos de trabajo de automatización o los sistemas de integración y entrega continuas deben invocar las API sin la presencia de un usuario. Los inquilinos se autentican a través de sus propios idP mediante identidades de carga de trabajo. La aplicación autoriza el acceso mediante la validación de declaraciones con ámbito de inquilino.

Es posible que este patrón no sea adecuado cuando tenga:

• Un IdP. En este escenario, los usuarios de la aplicación se autentican mediante un IdP y no necesitan autenticarse mediante otro IdP. Esta situación es habitual en las aplicaciones que usan un directorio corporativo para la autenticación, ya sea a través de una VPN o una conexión de red virtual entre la aplicación y un directorio local.

• Mecanismos de autenticación incompatibles. En este escenario, la aplicación usa un mecanismo de autenticación diferente, por ejemplo, mediante almacenes de usuarios personalizados o no puede controlar los estándares de negociación de tecnología basada en notificaciones. Puede ser complejo y costoso volver a ajustar la autenticación basada en notificaciones y el control de acceso a una aplicación existente.

Diseño de cargas de trabajo

Evalúe cómo usar el patrón de identidad federada en el diseño de una carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. En la tabla siguiente se proporciona una guía sobre cómo este patrón apoya los objetivos de cada pilar.

Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.

Example

Una organización hospeda una aplicación basada en la nube multicomponente que incluye un front-end web y una API de back-end. La aplicación delega la autenticación a un IdP centralizado mediante Microsoft Entra ID, en lugar de implementar la lógica de autenticación en cada componente.

Descargue un archivo de Visio de esta arquitectura.

El siguiente flujo de trabajo corresponde al diagrama anterior.

1. El usuario accede a la aplicación web.

2. La aplicación web redirige al usuario a Microsoft Entra ID para la autenticación.

3. Después de la autenticación correcta, Microsoft Entra ID redirige al usuario de nuevo a la aplicación web con un código de autorización.

4. La aplicación web intercambia el código de autorización de los tokens y envía una solicitud POST al punto de conexión del token.

5. Microsoft Entra ID emite un token que contiene declaraciones sobre el usuario.

6. La aplicación web usa este token para llamar a una API de back-end.

7. La aplicación web y la API de back-end validan el token y aplican sus reglas de autorización en función de las declaraciones.

8. La API devuelve la respuesta a la aplicación web.

Características clave:

• Autenticación centralizada. Los componentes se basan en Microsoft Entra ID para autenticar a los usuarios, lo que elimina la necesidad de lógica de autenticación personalizada en la aplicación.

• Autorización descentralizada. Los componentes de la aplicación hacen cumplir de forma independiente las decisiones de autorización basadas en declaraciones.

• Control de acceso basado en declaraciones. El acceso a la funcionalidad se determina mediante declaraciones, como roles o alcances.

• Protocolos basados en estándares. Los componentes usan OAuth 2.0 y OpenID Connect para la autenticación.

• Aplicación opcional de MFA. Si el perfil de riesgo requiere una mayor garantía de inicio de sesión, puede aplicar la autenticación multifactor mediante directivas de acceso condicional en Microsoft Entra ID.

• Extensibilidad opcional mediante federación. Microsoft Entra ID se puede configurar para confiar en un inquilino de Microsoft Entra asociado mediante la configuración de acceso entre inquilinos. Después, los usuarios asociados pueden acceder a la aplicación sin cambios en los componentes de la aplicación.

Pasos siguientes

• ¿Qué es Microsoft Entra?
• OpenID Connect en la plataforma de identidad de Microsoft
• Conversión de una aplicación de un solo inquilino en multiinquilino mediante Microsoft Entra ID
• ¿Qué es el acceso condicional?

Recursos relacionados

• Consideraciones de arquitectura para la identidad en una solución multiinquilino
• Patrón Gatekeeper
• Patrón Valet Key.
• Patrón de descarga del Gateway