Vamos a hablar de la federación de identidades e inicio de sesión único.
Federación de identidades que utiliza SSO dentro y/o entre organizaciones, incluido el utilización de proveedores de identidad, mitiga los riesgos mediante la gestión centralizada de las diferencias en políticas y niveles de riesgo entre las organizaciones y elimina una amplia implementación y dependencia de las identidades locales.
Sin definir formalmente las políticas y niveles de confianza y aseguramiento entre organizaciones o entre múltiples proveedores de identidad dentro de una organización, la organización es susceptible a ataques basados en las debilidades de cada IAM federado.
SSO proporciona una capacidad de mitigación de riesgos al centralizar la gestión y control de autenticación y acceso a través de múltiples sistemas y desde múltiples proveedores de identidad.
Si se implementa correctamente, también puede aumentar la garantía de autenticación de nivel requerido para el inicio de sesión inicial y puede controlar y asegurar la autenticación y información de autorización transmitida entre sistemas.
Identity Federation y SSO simplifican la gestión de identidades internamente dentro de una empresa y con socios externos confiables al reducir la necesidad de que los usuarios mantengan múltiples identidades en directorios, aplicaciones y otras plataformas tanto internas como externas, eliminando la necesidad de identidades locales en cada activo.
Permite una integración perfecta con otros controles de seguridad, como la gestión de acceso privilegiado para una autenticación mejorada, y aumenta la confianza de que solo se permite el acceso a los usuarios activos.
Además, reduce los costos laborales asociados con la gestión de múltiples identidades para cada usuario en las distintas aplicaciones locales y/o basadas en la nube.
Las contraseñas son una vulnerabilidad debido a la complejidad de exigir que un usuario recuerde contraseñas de varios caracteres que casi todas las aplicaciones requieren en la actualidad.
SSO nominalmente reduce la carga del usuario para recordar una frase de contraseña sólida, compleja y difícil de adivinar, y facilita la migración a MFA segura, eliminando potencialmente las contraseñas por completo.
La implementación de Identity Federation y SSO que admitan MFA sólida permite mejorar la seguridad sin comprometer la experiencia del usuario.
Las cuentas aprovisionadas localmente (por ejemplo, usuario, sistema, proceso, administrador) en activos individuales crean un entorno inmanejable y son un objetivo lucrativo para los malos actores.
Por ejemplo:
- Las cuentas aprovisionadas localmente pueden permitir o no la aplicación de políticas de seguridad.
Gestión de identidades y acceso: mejores prácticas recomendadas para administradores.
- No se pueden mantener volúmenes masivos de cuentas aprovisionadas localmente en sistemas individuales de toda la empresa. Estas cuentas pueden incluir cuentas compartidas, cuentas predeterminadas de proveedores y cuentas desconocidas (por ejemplo, ex empleado, ex proveedor).
- La supervisión de eventos de seguridad no es efectiva en cuentas aprovisionadas localmente. Por ejemplo, la capacidad de monitorear y detectar cuentas compartidas, credenciales robadas y credenciales descifradas (por ejemplo, difusión de contraseñas) es considerablemente más difícil dados los volúmenes de activos, cuentas y configuraciones de activos individuales.
- Los adversarios, tanto actores de amenazas internos como externos, pueden explotar las brechas en la política de seguridad y/o el monitoreo de eventos de seguridad en un sistema para comprometer los activos que administra y utilizar su acceso como punto de apoyo para lanzar ataques contra otros sistemas.
Identity Federation y SSO reducen drásticamente la necesidad de cuentas aprovisionadas localmente y permiten a los administradores de IAM tener una visibilidad y un control más centralizados sobre las cuentas.
También permite una gestión más eficaz de las cuentas predeterminadas y/o compartidas que se requieren en un activo individual.
Por ejemplo, la mayoría de las cuentas predeterminadas y compartidas se pueden deshabilitar y a aquellas que no se pueden deshabilitar se les pueden cambiar las contraseñas a valores altamente aleatorios protegidos en una bóveda de contraseñas.
Factores a considerar al seleccionar una solución SSO
Los servicios SSO pueden utilizar diferentes protocolos, como SAML u Open ID Connect (OIDC).
Al seleccionar un servicio SSO, es importante tener en cuenta los siguientes factores:
- ¿Qué protocolo se está utilizando?
- ¿Cómo ha asegurado el proveedor de servicios el protocolo y el servicio?
SAML:
SAML se utiliza para intercambiar datos de autenticación y autorización entre proveedores de identidad y proveedores de servicios.
Uno de los casos de uso más comunes de SAML es facilitar el SSO basado en navegador.
Hasta los últimos años, SAML se consideraba el estándar de la industria y el caballo de batalla probado para pasar un usuario autenticado a las aplicaciones y al mismo tiempo permitir que estas aplicaciones difieran la autenticación a una solución de identidad centralizada.
Si los servicios utilizan SAML, es imprescindible implementar medidas específicas y reforzarlas para que sea una opción de SSO segura, ya que es propensa a sufrir vulnerabilidades si no se implementa correctamente.
Cada año surgen nuevos problemas con SAML (en forma de exploits recién descubiertos), lo que le da la reputación de no ser la opción más segura.
OIDC se creó para abordar algunas de las fallas de SAML.
Sin embargo, SAML todavía se considera una opción relevante para SSO y todavía existen requisitos para que los desarrolladores lo admitan en entornos modernos.
Conexión OpenID:
OAuth 2.0 está diseñado únicamente para autorizar el acceso a datos y funciones de una aplicación a otra. OIDC es una capa delgada que se encuentra encima de OAuth 2.0 y agrega inicio de sesión. e información de perfil sobre la persona que ha iniciado sesión.
OIDC permite escenarios en los que un inicio de sesión se puede utilizar en varias aplicaciones (es decir, SSO). Una aplicación podría soportar SSO utilizando servicios de redes sociales (es decir, Facebook o Twitter) para que los usuarios puedan elegir aprovechar un inicio de sesión que ya tienen.
El flujo del código de autorización permite que las aplicaciones primero obtener códigos de autorización en lugar de obtener tokens directamente desde la devolución de llamada de autorización pedido.
Luego utiliza estos códigos en una solicitud a otro punto final en la autorización servidor para intercambiarlos por los tokens que necesitan.
La ventaja más significativa que el flujo que tiene en relación con el flujo implícito es su seguridad.
Hay dos características de la flujo de código de autorización que lo convierte en una mejor opción que SAML cuando se trata de seguridad.
Primero, el proceso para intercambiar códigos por tokens ocurre en canales secundarios.
En lugar de que los tokens viajen a través de los dispositivos de los usuarios, la aplicación abre una conexión de canal posterior al servidor de autorización, lo que elimina la necesidad de pasar credenciales y otra información a través de los dispositivos de los usuarios (como navegadores).
Al establecer una conexión directa entre sí, la aplicación y el servidor de autenticación reducen las posibilidades de que ciertas credenciales queden expuestas.
Al registrar una aplicación web, la configuración de devolución de llamada es importante desde el punto de vista de la seguridad porque restringe las URL a las que el proveedor OIDC puede llamar después de un proceso de autenticación exitoso.
La segunda característica es que, antes de emitir tokens, los servidores de autorización requieren que las aplicaciones se autentiquen.
Este proceso de autenticación generalmente ocurre mediante aplicaciones que utilizan credenciales que les asignan los servidores de autorización.
https://portswigger.net/web-security/oauth/grant-types
En resumen, OIDC es un protocolo más seguro y confiable porque utiliza un canal directo entre las aplicaciones y el servidor de autenticación, protegiendo los tokens de identidad.
Podeis echar un ojo al Azure SSO.
Inicio de sesión único (SSO) de Microsoft Entra | Seguridad de Microsoft
Y seguiremos tratando temas de seguridad.
Un saludo
