¿Qué son las federaciones?
El proceso de federación en sistemas de identidad se refiere a la capacidad de establecer una relación de confianza entre diferentes dominios u organizaciones. Esto permite que los usuarios inicien sesión en sistemas de terceros utilizando sus credenciales ya existentes, sin la necesidad de crear nuevas cuentas. Esta comunicación entre proveedores de identidad (IdPs) y proveedores de servicio (SPs) permite que la autenticación sea centralizada y reutilizable entre sistemas distintos.
Las federaciones permiten a nuestros clientes utilizar las cuentas que ya tienen para acceder a los recursos de sus respectivas empresas e iniciar sesión en la plataforma Blip. Esto facilita que el cliente gestione a su preferencia los controles de acceso y los protocolos de seguridad, además de simplificar el control de incorporación (onboarding) y desvinculación (offboarding) de usuarios. Esto no solo simplifica la experiencia del usuario, sino que también reduce el esfuerzo de administración y aumenta la seguridad, ya que los datos de autenticación permanecen bajo el control del IdP original.
¿Para qué sirven y para qué casos de uso están indicadas?
La federación resuelve problemas comunes como la duplicidad de cuentas, la gestión descentralizada de credenciales y el riesgo de filtración de contraseñas. En lugar de que el usuario mantenga decenas de inicios de sesión y contraseñas, se autentica una única vez en su IdP de confianza, y la federación garantiza que los otros sistemas acepten esa autenticación a través de protocolos como SAML y OpenID Connect.
En resumen, la federación es una pieza esencial para posibilitar escenarios de Single Sign-On (SSO) entre sistemas independientes, facilitar el uso de identidades sociales (como Google o Facebook) en aplicaciones web, e integrar sistemas antiguos (legados) con plataformas modernas de autenticación. Es especialmente relevante en arquitecturas modernas basadas en microservicios o múltiples interfaces de usuario (front-ends) que dependen de una identidad común para funcionar de manera integrada.
Protocolos soportados por Blip
Actualmente, Blip soporta dos protocolos ampliamente conocidos en la industria: OpenID Connect y SAML 2.0.
OpenID Connect (OIDC)
OpenID Connect (OIDC) es un protocolo de autenticación moderno, construido sobre el protocolo OAuth 2.0. Fue creado para permitir que las aplicaciones verifiquen la identidad de un usuario basándose en la autenticación realizada por un proveedor de confianza. OIDC es ampliamente utilizado en la web moderna por ser ligero, seguro, interoperable y fácil de integrar.
Una de las ventajas de OIDC es su simplicidad para los desarrolladores. Con pocos puntos finales (endpoints) estandarizados, soporte a JSON y uso extensivo de HTTPS, se adapta bien a aplicaciones web, móviles y APIs. Además, al estar basado en estándares abiertos, es compatible con diversos proveedores de identidad, como Google, Entra ID (antes Azure AD), Okta y muchos otros.
SAML 2.0 (En proceso de homologación)
SAML 2.0 (Security Assertion Markup Language) es un protocolo de autenticación popular en entornos corporativos y sistemas legados. Sin embargo, al estar basado en XML e implicar una configuración más compleja (como intercambio de metadatos, certificados y puntos finales), SAML 2.0 es considerado más "pesado" en comparación con OpenID Connect. Aún así, sigue siendo extremadamente relevante en contextos donde ya existe una infraestructura de autenticación SAML o donde la compatibilidad con sistemas antiguos es un requisito.
¿Cómo funciona?
Independientemente del protocolo utilizado, el funcionamiento general es prácticamente el mismo y se describe en el siguiente diagrama. El diagrama ha sido simplificado para facilitar la comprensión, eliminando componentes que no están directamente relacionados con el proceso en cuestión.
El usuario accede a uno de los productos Blip (BlipPortal o BlipDesk), que verifica si existe una sesión activa. Si es así, el usuario recibe acceso al sistema; si no, pasa al paso 2.
El usuario es dirigido al Proveedor de Identidad (IdP) de Blip. Si existe una sesión activa de este usuario, el Blip IdP devuelve a la aplicación cliente los tokens de acceso (SSO). Si no hay sesión activa, pasa al paso 3.
El Blip IdP identifica que existe una federación registrada para el contrato y dirige al usuario al Proveedor de federación del cliente dueño del contrato.
El Proveedor de federación dirige al usuario a su propia página de inicio de sesión (Sign In), donde se lleva a cabo el proceso de autenticación.
El usuario introduce su nombre de usuario, contraseña, ejecuta la autenticación multifactor (MFA), en fin, sigue el proceso de autenticación definido por el cliente.
Una vez que el usuario está autenticado, el Proveedor de federación devuelve al Blip IdP los tokens de acceso que contienen los datos del usuario, como el correo electrónico, por ejemplo.
El Blip IdP devuelve a la aplicación cliente los tokens de acceso que permiten la apertura de una sesión para el usuario.
Limitaciones
El proceso de federaciones en Blip actualmente tiene las siguientes limitaciones:
El campo correo electrónico es obligatorio y debe ser proporcionado por el Proveedor de Federaciones del cliente, siendo utilizado en Blip como identificador del usuario.
No realizamos la sincronización automática de permisos de un usuario entre el Proveedor de Federaciones del cliente y el Proveedor de Identidades de Blip.
No realizamos la eliminación/desactivación automática de cuentas cuando son eliminadas/desactivadas en el Proveedor de Federaciones del cliente. Sin embargo, estamos en proceso de desarrollar una API que permitirá automatizar la eliminación de todos los accesos de la plataforma en el proceso de desvinculación (offboarding), por ejemplo.
Para obtener más información, visita la discusión sobre el tema en nuestra comunidad o los vídeos en nuestro canal. 😃