Skip to content

Single Sign-On en la Nube: Federación

 
Durante los últimos años la contratación de servicios en la nube por parte de empresas y usuarios particulares se ha multiplicado de forma exponencial. Nuestro correo, nuestro almacenamiento y las herramientas que usamos en nuestro día a día ya no están instalados en nuestro equipo de trabajo, permitiéndonos ajustar el coste a lo que realmente necesitamos y facilitándonos el escalado en caso de necesitarlo. No obstante, al tener que trabajar con varias aplicaciones de varios fabricantes, almacenadas en una misteriosa “nube”, nos enfrentamos a nuevos problemas.
Uno de los más preocupantes es el asunto de la autenticación. ¿A quién delegamos esta tarea?, ¿dónde residen las contraseñas?, ¿y la información de los usuarios?, ¿tengo que introducir un usuario y contraseña en cada aplicación?
La solución por las que apuestan los proveedores de SaaS (Software as a Service) es, con mucha diferencia, la federación. Basándose en un conjunto de aplicaciones “federadas” que confían por completo la autenticación y autorización de usuarios en un tercer servidor central. Sigue los mismos principios que seguían protocolos de autenticación más antiguos como podía ser el caso de Kerberos, pero mejorando los problemas que presentaba este y orientándolo al mundo web.
 
 

Entorno sin federar

Ilustración1: ENTORNO SIN FEDERAR

 
 

Entorno federado

Ilustración 2: ENTORNO FEDERADO

 
Una vez decidido que vamos a federar nuestras aplicaciones nos toca elegir qué tecnología utilizar. Dentro de las muchas opciones que disponemos, destacan tres de ellas: SAML, oAuth y OpenID. Aunque tienen diferencias esenciales entre ellas, realmente no compiten entre sí, sino que dan solución a distintas necesidades.
De esta manera OpenID, patrocinado por grandes proveedores como Google, Facebook, Microsoft, Yahoo, etc., está orientado a los usuarios que diariamente consumimos servicios en la web y muy extendido en el mundo de las redes sociales. oAuth, sin embargo, está pensado para todas aquellas “apps” que buscan la autorización en servicios en la nube.
Por último está SAML, pensado para el mundo “enterprise” porque, a pesar de que su implementación es algo más compleja que OpenID, ofrece una gran robustez y seguridad, rasgos imprescindibles para las aplicaciones de una gran corporación.
SAML (Security Assertion Markup Language) no es una tecnología nueva. Su primera versión se registró en 2001 y la versión 2.0, utilizada hasta día de hoy, fue liberada en marzo del 2005. En esos momentos era algo extraordinario que una compañía decidiese externalizar cualquier servicio poniéndolo en manos extrañas y lejos de sus oficinas y no fue hasta varios años después, con la expansión de los entornos “nube”, cuando SAML se afianzó en los proveedores de servicios nube, apareciendo en las aplicaciones de los grandes fabricantes como Microsoft, Citrix, Google, etc.

arquitectura SAML 20

Ilustración 3: ARQUITECTURA SAML 2.0

 
SAML nos proporciona los mecanismos para detectar que un usuario ha iniciado sesión en cualquiera de estas aplicaciones evitando volver a solicitar usuario y contraseña si el mismo usuario quiere acceder a otra de las aplicaciones del entorno, creando así un entorno federado. Además, no es necesario que las aplicaciones remotas guarden los datos de los usuarios, con lo que nos proporciona un usuario y contraseña únicos y evita que datos críticos como las contraseñas viajen por la red.
La arquitectura SAML tiene dos componentes básicos:

  • El Service Provider (SP), que es el elemento, residente en cada aplicación, que es capaz de delegar la autenticación y autorización de usuarios en otro servidor.
  • El Identity Provider (IdP), que se encarga de mantener la información de usuarios, recibir las peticiones de acceso de las aplicaciones y decidir si la aplicación debe dejar acceder al usuario porque ya tiene una sesión activa en el entorno, o si debe pedirle su identificación.

Los proveedores de servicios, en su mayoría, ofrecen los SP de fácil configuración, pero la compañía debe disponer de alguna herramienta, de las muchas que hay en el mercado, que le ofrezca las funciones de IdP y autenticación de los usuarios.
Un ejemplo de herramienta de este tipo es WBSVision, un producto Open Source que ofrece múltiples funcionalidades relacionadas con la gestión de la identidad, sin ninguno de los inconvenientes del software privado. Así, entre sus funcionalidades podemos encontrar:

  • Directorio para almacenamiento y autenticación de usuarios
  • Motor IdM para provisión y ejecución de workflows
  • Rol IdP para SSO con SAML

Como conclusión, diremos que la gestión de la entidad en entornos “nube” para grandes organizaciones es imprescindible, ya no solo por lo que supone gestionar de forma local los usuarios de tantas aplicaciones, si no por los problemas de seguridad que este tipo de administración puede causar. Diremos, también, que un sistema de login único es muy deseable para mejorar la experiencia de los usuarios. La tecnología que nos proporciona ambas cosas en un entorno “enterprise” es SAML y, si optamos por un producto con las inmensas ventajas del mundo Open, WBSVision ofrece, sin duda, la solución más completa.
 
Descárgate el Artículo completo_Single Sing-on_Martín Domínguez.pdf

AYUDA SOBRE PRODUCTOS
WBSAirback
Almacenamiento y backup en un appliance open source.

WBSVision
Gestión y federación de identidades en un appliance open source.

SmartLogin
Single Sign-on y federación
CONTACTO

Contacta con nosotros: comercial@whitebearsolutions.com