La autenticación se delega a un proveedor de identidad externo. Esto puede simplificar el desarrollo, minimizar los requisitos de administración de usuarios y mejorar la experiencia del usuario de la aplicación.
Contexto y problema
Normalmente, los usuarios deben trabajar con varias aplicaciones que proporcionan y hospedan diversas organizaciones con las que mantienen una relación de negocios. A estos usuarios se les puede exigir que usen cada uno de ellos credenciales específicas (y diferentes). Esta situación puede dar lugar a:
Una experiencia de usuario desestructurada. Con frecuencia, los usuarios olvidan las credenciales de inicio de sesión cuando si tienen muchas diferentes.
Exposición de las vulnerabilidades de seguridad. Cuando un usuario abandona la empresa, la cuenta se debe desaprovisionar inmediatamente. En organizaciones de gran tamaño, es fácil pasarlo por alto.
Administración de usuarios complicada. Los administradores deben administrar las credenciales de todos los usuarios y realizar tareas adicionales, como proporcionar recordatorios de contraseña.
Los usuarios prefieren normalmente usar las mismas credenciales en todas estas aplicaciones.
Solución
Implemente un mecanismo de autenticación que pueda usar la identidad federada. Separe la autenticación de usuarios del código de aplicación, y delegue la autentificación a un proveedor de identidades de confianza. Esto puede simplificar el desarrollo y permitir que los usuarios se autentiquen mediante una variedad más amplia de proveedores de identidades (IdP) al tiempo que se reduce la sobrecarga administrativa. También permite separar claramente la autenticación de la autorización.
Entre los proveedores de identidades de confianza se incluyen directorios corporativos, servicios de federación locales, otros servicios de token de seguridad (STS) que proporcionan los asociados comerciales o proveedores de identidades sociales que pueden autenticar a los usuarios que tienen, por ejemplo, una cuenta de Microsoft, Google, Yahoo! o Facebook.
En la siguiente figura se ilustra el patrón Federated Identity (Identidad federada) cuando una aplicación cliente necesita acceder a un servicio que requiere autentificación. La autenticación se realiza mediante un IdP que trabaja en combinación con un STS. El IdP emite tokens de seguridad que proporcionan información sobre el usuario autenticado. Esta información, conocida como notificaciones, incluye la identidad del usuario y también podría incluir otra información como la pertenencia a un rol y derechos de acceso más específicos.
Este modelo se conoce a menudo como control de acceso basado en notificaciones. Las aplicaciones y los servicios autorizarán el acceso a las características y funcionalidades en función de las notificaciones contenidas en el token. El servicio que requiere autenticación debe confiar en el IdP. La aplicación cliente se pone en contacto el IdP que realiza la autenticación. Si la autenticación es correcta, el IdP devuelve un token que contiene las notificaciones que identifican al usuario en el STS (tenga en cuenta que el IdP y el STS pueden ser el mismo servicio). El STS puede transformar y aumentar las notificaciones en el token según reglas predefinidas, antes de devolverlo al cliente. La aplicación cliente puede luego pasar este token al servicio como prueba de su identidad.
Podría haber servicios de token de seguridad adicionales en la cadena de confianza. Por ejemplo, en el escenario descrito más adelante, un STS local confía en otro STS que es responsable de acceder a un proveedor de identidades para autenticar al usuario. Este enfoque es común en escenarios empresariales donde hay un STS y un directorio locales.
La autenticación federada proporciona una solución basada en estándares al problema de confiar en identidades de dominios diferentes y puede admitir el inicio de sesión único. Este tipo de autenticación es cada vez más común en todos los tipos de aplicaciones, especialmente en las aplicaciones hospedadas en la nube, ya que admite el inicio de sesión único sin necesidad de una conexión de red directa a los proveedores de identidades. El usuario no tiene que especificar credenciales en cada aplicación. Esto aumenta la seguridad, ya que, por una parte, impide la creación de las credenciales necesarias para acceder a muchas aplicaciones diferentes y, por otra, oculta las credenciales del usuario de todos, excepto del proveedor de identidades original. Las aplicaciones ven solo la información de la identidad autenticada contenida en el token.
La identidad federada tiene la ventaja principal de que la administración de identidades y credenciales es responsabilidad del proveedor de identidades. La aplicación o el servicio no necesitan proporcionar características de administración de identidades. Además, en escenarios corporativos, el directorio corporativo no necesita saber nada del usuario si confía en el proveedor de identidades. Como consecuencia, se elimina la sobrecarga administrativa de la administración de la identidad del usuario dentro del directorio.
Problemas y consideraciones
Al diseñar aplicaciones que implementan la autenticación federada, considere los siguientes puntos:
La autenticación puede ser un único punto de error. Si implementa la aplicación en varios centros de datos, considere la posibilidad de implementar el mecanismo de administración de identidades en los mismos centros de datos para mantener la disponibilidad y confiabilidad de la aplicación.
Las herramientas de autenticación le permite configurar el control de acceso en función de las notificaciones de rol contenidas en el token de autenticación. Con frecuencia a esto se le conoce como control de acceso basado en roles (RBAC) y puede permitir un nivel de control más específico sobre el acceso a las características y recursos.
A diferencia de los directorios corporativos, autenticación basada en notificaciones mediante proveedores de identidades sociales normalmente no proporciona información sobre el usuario autenticado, a excepción de una dirección de correo electrónico y quizás un nombre. Algunos proveedores de identidades sociales, como una cuenta de Microsoft, proporcionan solo un identificador único. Normalmente, la aplicación debe mantener cierta información de los usuarios registrados y poder relacionar esta información con el identificador contenido en las notificaciones del token. Por lo general, esto se consigue mediante el registro cuando el usuario accede a la aplicación por primera vez, y la información se introduce en el token como notificaciones adicionales después de cada autenticación.
Si hay más de un proveedor de identidades configurado para el STS, este debe determinar el proveedor de identidades al que se debe redirigir al usuario para la autenticación. Este proceso se denomina detección de dominios de inicio. El STS puede realizarlo automáticamente, pero necesitaría que el usuario especificara una dirección de correo electrónico o un nombre de usuario, un subdominio de la aplicación a la que accede el usuario, el ámbito de la dirección IP del usuario o el contenido de una cookie almacenada en el explorador del usuario. Por ejemplo, si el usuario escribió una dirección de correo electrónico en el dominio de Microsoft, como user@live.com, el STS redirigirá al usuario a la página de inicio de sesión de cuenta de Microsoft. En visitas posteriores, el STS podría usar una cookie para indicar que el último inicio de sesión fue con una cuenta de Microsoft. Si la detección automática no puede determinar el dominio de inicio, el STS mostrará una página de detección de dominios de inicio con los proveedores de identidades de confianza, entre los cuales el usuario debe seleccionar el que quiera usar.
Cuándo usar este patrón
Este patrón es útil en escenarios como:
Inicio de sesión único en la empresa. En este escenario debe autenticar a los empleados en las aplicaciones corporativas que se hospedan en la nube fuera del límite de seguridad corporativo, sin exigirles que inicien sesión cada vez que visitan una aplicación. La experiencia de los usuarios es la misma que cuando usan aplicaciones locales donde se autentican al iniciar sesión en una red corporativa y desde ese momento tienen acceso a todas las aplicaciones pertinentes sin necesidad de iniciar de nuevo la sesión.
Identidad federada con varios asociados. En este escenario, debe autenticar a los usuarios corporativos y a los asociados comerciales que no tienen cuentas en el directorio corporativo. Esta situación es común en aplicaciones de negocio a negocio, aplicaciones que se integran con servicios de terceros y en aquellos casos en que las empresas con diferentes sistemas de TI han combinado o compartido los recursos.
Identidad federada en aplicaciones SaaS. En este escenario, fabricantes independientes de software proporcionan un servicio listo para usar para varios clientes o inquilinos. Cada inquilino se autentica mediante un proveedor de identidades adecuado. Por ejemplo, los usuarios empresariales usarán sus credenciales corporativas, mientras que los consumidores y clientes del inquilino utilizarán sus credenciales de identidades sociales.
Este patrón podría no ser útil en las siguientes situaciones:
Todos los usuarios de la aplicación se pueden autenticar mediante un proveedor de identidades, y no hay ningún requisito para autenticarlos con cualquier otro proveedor de identidades. Esto es habitual en aplicaciones empresariales que utilizan un directorio corporativo (accesible dentro de la aplicación) para la autenticación, mediante una VPN o (en un escenario hospedado en la nube) a través de una conexión de red virtual entre el directorio local y la aplicación.
La aplicación se creó originalmente mediante un mecanismo de autenticación diferente, quizás con almacenes de usuario personalizados, o no tiene la funcionalidad para gestionar los estándares de negociación utilizados por tecnologías basadas en notificaciones. Retroadaptar la autenticación basada en notificaciones y el control de acceso en las aplicaciones existentes puede ser complejo y, probablemente, poco rentable.
Diseño de cargas de trabajo
El arquitecto debe evaluar cómo se puede usar el patrón de identidad federada en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Marco de la Well-Architected de Azure. Por ejemplo:
| Fundamento | Cómo apoya este patrón los objetivos de los pilares |
|---|---|
| Las decisiones de diseño de la fiabilidad ayudan a que la carga de trabajo sea resistente a los errores y a garantizar que se recupere a un estado de pleno funcionamiento después de que se produzca un error. | Descargar la gestión de usuarios y la autenticación traslada la fiabilidad de esos componentes al proveedor de identidades, que suele tener un SLO elevado. Además, durante la recuperación ante desastres de la carga de trabajo, es probable que no sea necesario abordar los componentes de autenticación como parte del plan de recuperación de la carga de trabajo. - RE:02 Flujos críticos - RE:09 Recuperación ante desastres |
| Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo. | Al externalizar la gestión y autenticación de usuarios, puede obtener funcionalidades evolucionadas para la detección y prevención de amenazas basadas en identidades sin necesidad de implementar estas funcionalidades en la carga de trabajo. Y los proveedores de identidad externos utilizan protocolos de autenticación modernos e interoperables. - SE:02 Ciclo de vida de desarrollo protegido - SE:10 Detección de amenazas y supervisión |
| La eficiencia del rendimiento ayuda a que la carga de trabajo satisfaga eficazmente las demandas mediante optimizaciones en el escalado, los datos y el código. | Al descargar la gestión y autenticación de usuarios, puede dedicar los recursos de la aplicación a otras prioridades. - PE:03 Selección de servicios |
Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.
Ejemplo
Una organización hospeda una aplicación de software como servicio (SaaS) inquilino múltiple de Microsoft Azure. La aplicación incluye un sitio web que los inquilinos pueden usar para administrar la aplicación para sus propios usuarios. La aplicación permite a los inquilinos acceder al sitio web mediante una identidad federada que genera Active Directory Federation Services (AD FS) cuando la instancia de Active Directory propiedad de esa organización autentica un usuario.
En la ilustración se muestra cómo los inquilinos se autentican con su propio proveedor de identidades (paso 1), en este caso AD FS. Después de autenticar correctamente un inquilino, AD FS emite un token. El explorador cliente reenvía este token al proveedor de federación de la aplicación de SaaS, que confía en los tokens emitidos por la instancia de AD FS del inquilino, con el fin de devolver un token que sea válido para el proveedor de federación de SaaS (paso 2). Si es necesario, el proveedor de federación de SaaS realiza una transformación de las notificaciones del token en notificaciones que la aplicación reconoce (paso 3) antes de devolver el nuevo token al explorador cliente. La aplicación confía en los tokens emitidos por el proveedor de federación de SaaS y usa las notificaciones del token para aplicar las reglas de autorización (paso 4).
No es preciso que los inquilinos recuerden distintas credenciales para acceder a la aplicación, y un administrador de la empresa del inquilino puede configurar en su propia instancia de AD FS la lista de usuarios que pueden acceder a la aplicación.
Pasos siguientes
- Microsoft Entra ID
- Active Directory Domain Services
- Servicios de federación de Active Directory
- Aplicaciones multiempresa en Azure