Notas sobre requisitos de un sistema de Single Sign On

Una única pantalla (IdP/AuthenticationServer/...) donde autenticar a los usuarios

Eso les proporciona mayor sensación de seguridad, nos permite centrar los mayores esfuerzos de seguridad y protección en este punto, así como implementar sólo aquí formas diversas y avanzadas de autenticación como usuario/clave, certificados, DNIe, etc.

Las aplicaciones que requieren autenticación no tienen acceso a las claves

Una aplicación que solicita usuario y clave tiene acceso a estos datos. En el caso de aplicaciones programadas y/o mantenidas por personas ajenas esto es un peligro potencial. Con sistemas de SSO, este peligro desaparece.

Envío de atributos junto con la aserción de autenticación

Muchas aplicaciones no sólo necesitan saber que quien accede es usuario de la institución, sino también otros datos como su nombre o el colectivo al que pertenece, para permitirle una acciones u otras. Algunos sistemas de SSO sólo permiten garantizar la autenticación y no el envío de atributos a las aplicaciones.

Un único punto accede a bases de datos de información de usuarios

Para entregar a las aplicaciones datos del usuario como hemos mencionado antes, el punto de autenticación debe ser autorizado a acceder a bases de datos y/o directorios corporativos. Si es un único servicio el que debe ser autorizado, la seguridad y el mantenimiento ante cambios mejora sensiblemente.

Posibilidad de pasar aserciones de autenticación a otros dominios

En sistemas de SSO multidominio, como las federaciones, aplicaciones alojadas en una institución pueden ser utilizadas por usuarios autenticados en otra.

Los usuarios no necesitan autenticarse en cada acceso a una nueva aplicación

Puesto que el IdP normalmente recuerda, mediante cookies, que en la misma sesión del navegador del usuario éste ya se ha autenticado previamente, puede responder a peticiones de autenticación sin necesidad de pedir de nuevo al usuario que se autentique. Esto es lo que se suele considerar la principal ventaja de estos sistemas, pero no deja de ser una comodidad para los usuarios, al contrario que los puntos anteriores que suponen ventajas funcionales y de seguridad.

Usaremos la nomenclatura de SAML para estos elementos: IdP (Identity Provider) y SP (Service Provider), aunque en otros sistemas reciban otros nombres, como AS (Authentication Server) y PoA (Point of Access) en el caso de PAPI.

Algunos de los requisitos que podemos (o no) exigir a un sistema de SSO son los siguientes:

Fácil de mantener, sobre todo los SPs

Un IdP puede (y debe) requerir mantenimeinto y actualización frecuentes, pero a medida que aumenta el número de aplicaciones protegidas, en muchas ocasiones mantenidas por personal ajeno, su mantenimiento puede ser imposible.

Posibilidad de funcionamiento en un entorno multidominio

Con el interés cada vez mayor en la integración en federaciones (ya tenemos SIR y hay que estar preparado para otras) los sistemas SSO que sólo funcionan dentro de un único dominio administrativo no son muy adecuados.

No se limite a autenticación y permita la entrega de atributos

Como ya hemos dicho, un gran número de aplicaciones necesitan información adicional del usuario, no sólo saber si se ha autenticado.

Permita integrarse en federaciones

Use (o exista la posibilidad de proxies o bridges con ellos) protocolos estandar o ampliamente utilizados

El despliegue de estos sistemas es costoso, disponemos ya de tecnologías establecidas y tiene poco sentido usar soluciones cerradas o muy específicas.

Permita su uso desde aplicaciones que usen distintos lenguajes de programación y servidores Web

En las universidades existen multitud de aplicaciones que potencialmente podrían beneficiarse de sistemas de SSO, implementadas en distintos lenguajes de programación y funcionando sobre distintos servidores Web. El sistema que usemos debería poder usarse con todos o la mayoría de ellos, sea nativamente o mediante proxies, bridges, etc. que haya dispponibles.

Posibilidad de integrarse con nuevos sistemas de autenticación y/o autorización

Lo más destacable en este sentido podría ser la integración OpenID, en ambos sentidos: proporcionar a nuestros usuarios un servicio de autenticación en sitios Web externos o aceptar accesos autenticados por proveedores de identidad externos (esto último menos probable). Y también contemplar Oauth para que cada usuario pueda controlar el acceso desde sitios externos a recursos alojados localmente o viceversa.