El Single Sign On, conocido por sus siglas en inglés como SSO, es una arquitectura de sistemas que le permite al usuario acceder a diferentes aplicaciones con una sola validación de acceso. ¿Cómo se puede lograr esto en un sitio web? ¿Existe algún riesgo?

Esta técnica se ha popularizado con el auge de las redes sociales, las aplicaciones web y la computación en la nube. Grandes compañías han querido simplificar la vida de sus usuarios permitiéndoles tener acceso a sus distintos productos con una misma cuenta. Puede entenderse el Facebook Connect como un tipo de SSO, sin embargo un ejemplo más claro sería Google Apps.

Con una sola cuenta, usted puede acceder a Gmail (gmail.com), Google Calendar (google.com/calendar), Google Maps (maps.google.com), Google Play (play.google.com), Youtube (youtube.com),  Google News (news.google.com), Google Docs (docs.google.com), etc… Como vemos, tenemos acceso a todos estos incluso a pesar de que algunos de estos sitios están ubicados en subdominios de google.com, otros son dominios completamente aparte y posiblemente estén distribuidos en múltiples servidores.

Hay diferentes aproximaciones para implementar un SSO, dependiendo del ambiente en el que se requiera. Es diferente hacer un SSO para dos sitios que están en el mismo servidor que para sitios que estén en distintos servidores o que tengan distintos dominios. A continuación analizamos diferentes escenarios en los que el SSO puede ser necesario.

SSO en el mismo servidor

La base del SSO es lograr compartir la información que identifica a cada usuario en la sesión. Si los sitios están en el mismo servidor y comparten el mismo dominio (es decir, existe un dominio principal abc.com y varios subdomios xyz.abc.com o def.abc.com) lo que debe hacerse es configurar las siguientes directivas:

• Debe modificarse el dominio de las cookies de modo que cada cookie sea creado con el dominio .abc.com.
• Debe asegurarse que todas las cookies se almacenen en el mismo lugar del servidor.
• El nombre de la sesión debe ser el mismo en todos los sitios.

Es posible que se tengan que desactivar algunas directivas de seguridad como el session referer check, que verifica que los cookies hayan sido creados en el mismo sitio. Por ello, es importante que el sitio tome en cuenta otras validaciones de seguridad como las que repasamos en este post.

SSO entre distintos servidores

El problema al intentar establecer una arquitectura SSO en servidores distintos es, por supuesto, que las Cookies no pueden almacenarse en la misma ubicación y por tanto, no pueden ser leídas por los sitios. Lo que necesitamos, entonces, es crear un espacio compartido en donde puedan alamcenarse estas Cookies. Para ello podemos usar Memcached.

Lo que hacemos es instalar Memcached en ambos servidores.

apt-get install memcached //si estamos utilizando php podemos usar php5-memcache

Ambos servidores deben configurarse, de modo que ambos almacenen las cookies de la sesión en Memcached. Memcached tiene un manejador de sesiones que facilita esta tarea. Por ejemplo, en PHP tendríamos que configurar el archivo php.ini para indicarle que utilice el manejador de sesiones de Memcached. Sólo uno de los servidores proveerá el servicio de almacenaje de las cookies de la sesión, los otros servidores se comunicarán con este para alamcenar sus sesiones. En el caso del servidor donde se almacenarán las sesiones usaremos algo como:

session.save_handler = memcache
session.save_path="tcp://127.0.0.1:port?persistent=1&weight=1&timeout=1&retry_interval=15"

y para el cliente

session.save_handler = memcache
session.save_path="tcp://IP_DEL_SERVIDOR:port?persistent=1&weight=1&timeout=1&retry_interval=15"

y listo! Normalmente, se utiliza el puerto 11211 por convención, pero se puede utilizar cualquier otro puerto disponible.La única salvedad es verificar que el puerto esté abierto y que se permita el acceso a los demás servidores, sobre todo si hay firewalls de por medio.
SSO entre distintos dominios

Si los sitios tienen distintos dominios, lo mejor es guardar las sesiones en bases de datos, de modo que cada sitio tome la información de los usuarios registrados desde allí. Claro que hay que tomar en cuenta que el costo de traer información desde una base de datos es mayor que el de obtenerla desde la memoria o el disco, como en el caso de las cookies. Hay que analizar el impacto que tendrá en el rendimiento del sitio y buscar métodos de caché de sesiones en caso de optar por el uso de bases de datos. En este apartado, Memcached también puede servir.

Tanto la configuración de cookies como guardar las sesiones en bases de datos permiten no solo guardar la información de los usuarios registrados, si no cualquier otra información que se almacene en la sesión. Sin embargo, cuando el requerimiento del SSO es solo para el registro de usuarios, es posible que, si se está trabajando sobre una plataforma Windows, se realice el registro de usuarios con el Active Directory. También es posible utilizar un servicio externo de registro de sesiones como OpenID.

En futuros posts analizaremos en detalle como implementar esta técnica utilizando CakePHP.