FACULTAT D’INFORMÀTICA DE BARCELONA
Single Sign-On
Miquel Trilla
FACULTAT D’INFORMÀTICA DE BARCELONA
Contenido de la presentación

¿Qué es Single Sign-On (SSO)?

Arquitecturas para un sistema SSO

Situación actual en la Facultat d’Informàtica de Barcelona

Conclusiones
FACULTAT D’INFORMÀTICA DE BARCELONA
¿Qué es Single Sign-On?

Definición Single Sign-on (SSO):
Concepto que consiste en la autentificación única por parte del
usuario para acceder a sus recursos
La idea es introducir una única vez el nombre de usuario y
contraseña, sin necesidad de volver introducirlo a la hora de acceder a
nuevos recursos en los que aún no se había autentificado.
FACULTAT D’INFORMÀTICA DE BARCELONA
¿Qué es Single Sign-On?

Características:



Multiplataforma: facilita las tareas de inicio de sesión y de
acceso a recursos de red desde distintas plataformas
Transparencia: el acceso a los recursos de sistemas se
efectúa de forma transparente al usuario debido a la
automatización del inicio de sesión
Facilidad de uso: el usuario se autentifica una única vez y el
sistema le permite acceder a los recursos para los cuales esta
autorizado. Así se evita las interrupciones producidas por la
solicitud de usuario y contraseña para el acceso a diferentes
recursos
FACULTAT D’INFORMÀTICA DE BARCELONA
¿Qué es Single Sign-On?

Características:



Gestión sencilla: el uso de SSO aconseja la sincronización de
contraseñas e información de los usuarios. Esto implica la
simplificación de la gestión de los recursos por parte de los
administradores.
Control de acceso: no se ve afectado por el uso de este
sistema, SSO implica cambiar los mecanismos de
autentificación del cliente y/o servidor, pero no modifica los
permisos de los recursos.
Seguridad: depende de la arquitectura usada, pero en todos los
casos la información viaja cifrada por la red
(SSL, certificados...)
FACULTAT D’INFORMÀTICA DE BARCELONA
Contenido de la presentación

¿Qué es Single Sign-On (SSO)?

Arquitecturas para un sistema SSO

Situación actual en la Facultat d’Informàtica de Barcelona

Conclusiones
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Clasificación

Clasificación de las arquitecturas SSO:
Simple
Basada en Tokens
Autentificación
Centralizada
Basada en PKI’s
SSO
Sincronización
de contraseñas
Compleja
Autentificación
Múltiple
Caché en
el cliente
Caché en
el servidor
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Solución simple

Single Sign-On con un único Servidor de Autentificación
Primer
Sign-On
Servidor de
Autentificación
Token
ID | PW
Confianza
Intercambio de
Autentificación
Validación
Recurso
ID | PW
BD de usuarios
ID
PW
ID
PW
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Solución simple

Etapas en la Solución Simple:
1.
2.
3.
El usuario desea acceder a un recurso. Se le pide un usuario y
una contraseña que son enviados al servidor de
autentificación.
El servidor de autentificación comprueba la validez de los
datos introducidos, y genera un token de sesión para el cliente.
El cliente envía al servidor del recurso que quiere acceder el
token recibido.
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Solución simple

Etapas en la Solución Simple:
4.
5.
6.
El servidor del recurso valida este token contra el servidor de
autentificación (existe una relación de confianza entre los
recursos y el servidor de autentificación).
Si el token es valido y se dispone de acceso al recurso, el
cliente puede acceder él. En caso contrario, se deniega su
acceso.
El usuario desea acceder a un nuevo recurso. De forma
transparente a él, el cliente envía el token al servidor del
recurso, repitiendo las etapas 4 y 5.
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Credencial unica

Single Sign-On basado en el paso de Token
Primer
Sign-On
Token
Token
Temporal
Autoridad de
Autentificación
Primaria
BD Primaria
ID
PW
ID
PW
ID | PW
Confianza
Segundo Sign-On
transparente usando
Token Temporal
Autoridad de
Autentificación
Secundaria
ID | PW
BD Secundaria
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Basado en token

Etapas en la Solución basada en Token:
1.
2.
3.
El usuario desea acceder a un recurso. Se le pide un usuario y
una contraseña que son enviados al servidor de autentificación
de ese recurso.
El servidor de autentificación comprueba la validez de los
datos introducidos, y genera un token de sesión para el cliente,
que le permite acceder al recurso.
El usuario desea acceder a un nuevo recurso que pertenece a
otra Autoridad de Autentificación. El cliente de forma
transparente envía el token recibido de la primera autoridad a
esta segunda.
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Basado en token

Etapas en la Solución basada en Token:
4.
5.
6.
La segunda Autoridad Autentificadora mantiene una relacion
de confianza con la primera Autoridad, con la que comprueba
la validez del token (o ticket).
El usuario tiene acceso a los recursos que pertenecen a la
segunda autoridad autentificadora gracias al token y a la
confianza establecida con el generador de ese token.
Ejemplos: Kerberos, Passport, …
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Credencial unica

Single Sign-On basado en el uso de PKI:
Registro
del Usuario
ID | PW
Emisión
Certificado
Clave
Privada
Autoridad de
Autentificación
Primaria
Certificado
Usuario
Confianza
BD
ID
PW
ID
PW
Certificado CA
Certificado CA
Segundo Sign-On
transparente usando Llave
Pública como Credencial
(Certificado y Clave
privada)
Autoridad de
Autentificación
Secundaria
Certificado CA
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Basado en PKI

Etapas en la Solución basada en PKI:
1.
2.
El usuario se da de alta en un centro de autentificación
(autoridad certificadora primaria) y recibe un certificado que
consta de una clave privada, otra publica e información sobre
la Autoridad certificadora y del usuario.
Cuando el usuario desea acceder a un servicio, éste le pide
autentificación. El servidor usa el certificado público como
credencial para comprobar la autentificación del cliente.
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Pros y Contras
Autentificación Centralizada
Basado en
Ventajas
Desventajas
Token

Tiene un único conjunto de
credenciales simplifica la vida al
administrador y al usuario.
 El software normalmente viene
incorporado con el Sistema.

Requiere una infraestructura de
autentificación homogénea.
 Se basa en criptografía simétrica.
PKI

Tiene un único conjunto de
credenciales simplifica la vida al
administrador y al usuario.
 El software normalmente viene
incorporado con el Sistema.
 Se basa en criptografía
asimétrica.

Solo puede trabajar con un único
conjunto de credenciales.
 Algoritmo complejo de validación
de certificado. Requiere mucho
cálculo en el lado del cliente.
 Requiere una infraestructura de
autentificación homogénea (todos
los servicios deben tener activado
el mecanismo PKI)
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Caché en Cliente

Single Sign-On con autentificación múltiple y basado en
caché cliente:
Token
Token
Primer
Sign-On
Autoridad de
Autentificación
Primaria
PW
Caché Cliente
Segura
ID | PW
ID | PW
BD Primaria
ID
PW
ID
PW
Confianza
Segundo Sign-On
transparente usando
credenciales
almacenadas en
cliente
Autoridad de
Autentificación
Secundaria
ID | PW
BD Secundaria
ID | PW
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Caché en Cliente

Etapas en la Solución Caché en el Cliente:
1.
2.
3.
El usuario introduce una contraseña para acceder a su base
de datos (almacenada en su ordenador).
En la base de datos se encuentran almacenadas las
credenciales (usuario y contraseña) de los dominios a los
cuales tiene acceso.
Cada vez que accedemos a un recurso de un dominio en el
que no estamos autentificados, el cliente envía de forma
transparente la credencial a la autoridad de autentificación, y
esta le devuelve un token de sesión para los recursos del
dominio.
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Caché en Cliente

Etapas en la Solución Caché en el Cliente:
4.
5.
Cuando el usuario accede aun recurso del cual no tiene la
credencial almacenada, el usuario introduce el nombre de
usuario y contraseña, y esta credencial queda almacenada en
la caché del cliente.
Existe una relación de confianza desde las autoridades de
autentificación secundarias con la primaria.
Ejemplos:
Windows XP, Windows .NET, Entrust Entellingence, …
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Caché en Servidor

Single Sign-On con autentificación múltiple y basado en
caché servidor:
Primer Sign-On
Token
Peticiones credenciales
sucesivas
Token
ID | PW
ID | PW
Autoridad de
Autentificación
Primaria
BD Primaria
ID
PW
ID
PW
Credenciales
para AAS1
Confianza
Segundo Sign-On
transparente usando
Credenciales
proporcionadas por
AAP2
1 Autoridad de Autentificación Secundaria
2 Autoridad de Autentificación Primaria
Autoridad de
Autentificación
Secundaria
ID | PW
BD Secundaria
ID | PW
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Caché en Servidor

Etapas en la Solución Caché en el Servidor:
1.
2.
3.
El usuario se valida en la primera autoridad de autentificación,
y le devuelve un token para acceder a los recursos del dominio
de esta autoridad.
Cuando el usuario desea acceder a un recurso que pertenece
a otra autoridad de autentificación, de forma transparente toma
la credencial de la segunda autoridad accediendo a la caché
de la primera.
El cliente usa esta credencial (usuario y contraseña) y se
valida en la segunda autoridad, devolviéndole esta un nuevo
token para su dominio de recursos.
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Caché en Servidor

Etapas en la Solución Caché en el Servidor:
4.
Existe una relación de confianza desde las autoridades de
autentificación secundarias con la primaria.
Ejemplos:
Tivoli SecureWay SSO, CA Entrust SSO, …
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Pros y Contras
Autentificación Múltiple
Basado en
Ventajas
Desventajas
Requiere una caché “segura” de
credenciales en el lado del cliente –
no recomendado su uso en
dispositivos portatiles.
 Múltiples gestores de
credenciales complica la vida al
usuario y al administrador.
Caché
Cliente

Puede trabajar con diferentes
gestores de credenciales.
 No requiere una infraestructura
de autentificación homogénea.
 Tiene un impacto importante en
el cliente (requiere software extra
o un SO que lo soporte).

Caché
Servidor

Puede trabajar con diferentes
gestores de credenciales.
 No requiere una infraestructura
de autentificación homogénea.
 Tiene un impacto importante en
el cliente (requiere software
extra).

Requiere un mecanismo de
sincronización de credenciales
(puede formar parte del producto
SSO).
 Múltiples gestores de
credenciales complica la vida al
usuario y al administrador.
 Requiere software extra en el
lado del servidor.
FACULTAT D’INFORMÀTICA DE BARCELONA
Arquitecturas SSO – Soluciones existentes

Las dos alternativas más importantes para
arquitecturas SSO actualmente son:


Liberty Alliance Project:
método basado en Federaciones
Passport.NET:
es el componente principal de la estrategia .NET i soporta KerberosV
FACULTAT D’INFORMÀTICA DE BARCELONA
Contenido de la presentación

¿Qué es Single Sign-On (SSO)?

Arquitecturas para un sistema SSO

Situación actual en la Facultat d’Informàtica de Barcelona

Conclusiones
FACULTAT D’INFORMÀTICA DE BARCELONA
Situación actual en la FIB

Actualmente en la FIB tenemos un arquitectura de autentificación
que se acerca al SSO simple.

Características:




Multiplataforma: Solaris, Windows 98, Windows XP, Linux
Sincronización de credenciales: único usuario y contraseña
para la autentificación.
Credenciales centralizadas: un único servidor de
autentificación valida los diferentes sistemas.
Seguridad: Uso de SSL (Secure Sockets Layer)
FACULTAT D’INFORMÀTICA DE BARCELONA
Situación actual en la FIB

Características de autentificación en diferentes
sistemas:




Credenciales centralizadas en un único servidor de
autentificación implementada en un servidor LDAP
(Lightweight Directory Access Protocol) con SSL.
Plataformas Solaris, Windows 98, XP y Linux que validan su
autentificación sobre el servidor LDAP mediante PAM
(Pluggable Authentication Modules).
Racó de la FIB autentificados mediante el modulo
mod_auth_ldap del servidor web Apache.
Correo de alumnos (IMAP/POP+SSL y Webmail)
autentificados mediante PAM.
FACULTAT D’INFORMÀTICA DE BARCELONA
Situación actual en la FIB

Esquema de la situación actual:
SSL
Replica del
Servidor
LDAP
Servidor
LDAP
PAM_LDAP
Servidor
FTP
SSL
SSL
SSL
SSL
MOD_AUTH_
LDAP
PAM_LDAP
PAM_LDAP
PAM_LDAP
Racò WEB
+ Webmail
Servidor
IMAP/POP
PC Aules
(Samba)
Terminales
(Solaris)
FACULTAT D’INFORMÀTICA DE BARCELONA
Situación actual en la FIB

Descripción de los sistemas que participan en la
autentificación:

Windows 98, XP y Linux sobre Arquitectura x86:
Autentificación mediante Samba sobre Enos y Laika.
•
•

Enos
Laika
Terminales Sunray sobre Arquitectura Ultra-SPARC:
Autentificación mediante PAM.
•
•
•
•
Moonrey
Universia
Ada
Solfoc
FACULTAT D’INFORMÀTICA DE BARCELONA
Situación actual en la FIB

Descripción de los sistemas que participan en la
autentificación:

Racó Web + Webmail desde Racó:
Autentificación mediante modulo LDAP de Apache.
•
•

FTP + POP/IMAP + Webmail fuera del Racó:
Autentificación mediante PAM.
•

Xino / Xano
Emilio
Emilio
LDAP:
Servicio de Directorio donde se almacenan las credenciales.
•
•
Xino / Xano
Sanrey
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Consideraciones

Consideraciones a tener en cuenta a la hora de realizar
la implantación de un sistema SSO:


Los verdaderos sistemas SSO requieren estar integrados en el
Sistema Operativo (Login / Logout)
El proceso de autentificación es realizado por diferentes
componentes según el SO (disparidad de mecanismos):
•
•
•
NT / 2K / XP: GINA - LSA
Netware: GINA (4.x) o NMAS (5.0)
UNIX / Linux: PAM, NIS …
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Consideraciones

Consideraciones a tener en cuenta a la hora de realizar
la implantación de un sistema SSO:

Especialmente molesto en el mundo Web:
•
•

¡ Se requiere hacer un login previo simplemente para acceder al
navegador y autentificarnos de nuevo !
Un buen sistema SSO debe contemplar la autentificación vía web
como una parte más del sistema
Un buen sistema SSO combina elementos de una VPN (Virtual
Private Network):
•
•
Transporte seguro a nivel de Gestión
Transporte seguro a nivel de Aplicación
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Técnicas

Desarrollo de una API intermedia:
Software
API

Ventajas:
•
•

Las librerías del sistema son siempre las más eficientes.
Más fácil de localizar puntos de seguridad dentro de la aplicación.
Inconvenientes:
•
•
•

Lib. Dinámica
Requiere retocar todas las aplicaciones.
Complicado de acoplar con aplicaciones existentes de hace
tiempo.
Imposible de llevar a cabo con aplicaciones externas.
Ejemplos: SASL, GSS-API, JAAS,…
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Técnicas

Reemplazo de Librerías Dinámicas (DLL/.so):
Software

Ventajas:
Lib. Dinámica
•
•

No hay que retocar las aplicaciones existentes.
Transparente a las aplicaciones.
Inconvenientes:
•
•
•
Puede provocar conflictos con alguna aplicación.
Difícil determinar exactamente que librerías hay que modificar
para que el sistema funcione. Varia según el sistema operativo.
Las actualizaciones del sistema operativo pueden destruir
nuestras librerías dinámicas.
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Técnicas

Reemplazo de las Aplicaciones:
Software

Ventajas:
•

El nivel más alto de transparencia.
Inconvenientes:
•
•
•
No es escalable (hay que cambiar TODO).
No es interoperable.
Se depende de la solución comercial.
API
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Kerberos

Kerberos: última versión - KerberosV


Es un método de autentificación que sigue la arquitectura
SSO basada en el paso de tokens, llamados aquí tickets.
La autentificación vía Kerberos funciona de la siguiente
manera:
•
El usuario se valida a un servidor de autentificación Kerberos que
le devuelve una clave de sesión, es un ticket general de
comunicación con el servidor de autentificación.
•
Cada vez que el cliente quiere acceder a un recuso, el servidor
de autentificación genera un ticket para el recurso determinado.
•
El servidor del recurso comprueba que el ticket enviado por el
cliente es válido, y permite el acceso.
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Kerberos

Soluciones kerberos para los diferentes servicios:

Soluciones SSH y SFTP:
•
•

Secure Shell (Windows, Unix y Linux)
OpenSSH (Unix, Linux y Windows con Cygwin)
Soluciones FTP y Telnet:
•
•
•
FileZilla (FTP para Windows)
FTP y Telnet del propio KerberosV (UNIX y Linux)
No se encuentran soluciones interesantes de telnet para
Windows.
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Kerberos

Soluciones kerberos para los diferentes servicios:

Soluciones Servidores Correo:
•
•
•

UW IMAP permite autentificación con Kerberos V.
Courier IMAP: mediante PAM
Cyrus IMAP: mediante SASL
Soluciones Clientes Correo:
•
•
•
Eudora Mail y aparentemente Outlook Express (Windows)
Uso de Evolution (Linux, y UNIX + Gnome)
Posibles problemas en Netscape Mail. Solución: Uso de filtros o
Servicio en lado cliente + Cliente Gráfico de Mail (UNIX, Linux y
Windows)
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Kerberos

Soluciones kerberos para los diferentes servicios:

Soluciones Web (webmail y racó)
•
PubCookie: permite SSO extendiendo cualquier tipo de
autentificación, pero hace falta generar la cookie al entrar.
•
Módulos Kerberos para Apache.
•
En Web existen múltiples soluciones que deben ser estudiadas y
probadas antes de elegir una, que se adapte fácilmente al resto
del sistema SSO.
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - Kerberos

Riesgos de seguridad en Kerberos:



Los problemas con claves de usuario sencilla se mantienen
(prueba y error, fuerza bruta ..)
Tampoco nos protege de ataques debidos a troyanos, como
por ejemplo una pagina de login falsa que captura lo que
introducimos en ella
Potencialmente es posible llegar a conseguir la clave que esta
siendo usada y utilizarla, aunque solo nos será útil durante el
tiempo de sesión (en nuestro caso esto sería difícil)
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - PKI

PKI: Certificados digitales


Este método de autentificación esta basado en
la arquitectura SSO con certificados digitales (PKI).
La autentificación mediante PKI funciona de la siguiente forma:
•
El usuario ha de tener un certificado digital formado por una clave
privada, otra clave publica y información de la autoridad
certificación y del propio usuario.
•
Cada vez que un cliente quiere acceder a un recurso, el servidor
solicita la autentificación mediante certificados. Para ello ha de
confiar en la autoridad certificadora que emite el certificado.
•
El servidor del recurso comprueba que la credencial (certificado)
del cliente es válido, y permite el acceso.
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - PKI

Soluciones PKI para los diferentes servicios:

Soluciones SSH y SFTP:
•
•

Soluciones FTP:
•

Secure Shell (Windows, Unix y Linux)
OpenSSH (Unix , Linux, Windows con Cygwin)
GSIFtp (UNIX, Linux y Windows, es un cliente java)
Soluciones Telnet:
•
No hemos encontrado soluciones que se autentifiquen mediante
certificados.
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - PKI

Soluciones PKI para los diferentes servicios:

Soluciones de Correo:
•
•

Indicar al servidor IMAP que use una autentificación externa
(mediante PAM o SASL).
Creación de un Servicio en el lado del cliente
Soluciones Web (webmail y racó)
•
PubCookie: permite SSO extendiendo cualquier tipo de
autentificación, pero hace falta generar la cookie al entrar.
•
Navegadores como Netscape, Internet Explorer, Mozilla,…
permiten utilizar la autentificación mediante certificados.
FACULTAT D’INFORMÀTICA DE BARCELONA
Implantación - PKI

Riesgos de seguridad en PKI:

Soluciones de Correo:
•
•

Indicar al servidor IMAP que use una autentificación externa
(mediante PAM o SASL).
Creación de un Servicio en el lado del cliente
Soluciones Web (webmail y racó)
•
PubCookie: permite SSO extendiendo cualquier tipo de
autentificación, pero hace falta generar la cookie al entrar.
•
Navegadores como Netscape, Internet Explorer, Mozilla,…
permiten utilizar la autentificación mediante certificados.
FACULTAT D’INFORMÀTICA DE BARCELONA
Contenido de la presentación

¿Qué es Single Sign-On (SSO)?

Arquitecturas para un sistema SSO

Situación actual en la Facultat d’Informàtica de Barcelona

Conclusiones
FACULTAT D’INFORMÀTICA DE BARCELONA
Conclusiones

La implementación / implantación de un sistema SSO siempre es
más compleja de lo que uno piensa inicialmente.

Analizar qué arquitectura encaja mejor en nuestro entorno.

Hay que realizar un análisis de requerimientos que nos marque
claramente unos objetivos:

Implementar el sistema de forma progresiva, por fases.
FACULTAT D’INFORMÀTICA DE BARCELONA
Conclusiones

Facilidad de uso y seguridad son características normalmente
contrapuestas:


Hay que tener una atención especial en este aspecto
No hay ningún producto que lo contemple todo:

Existen muchas maneras diferentes de hacer una cosa, hay que
buscar la combinación que resulte mejor en cada caso
Descargar

Diapositiva 1