Single Sign-On

1
Single Sign-On

• Miquel Trilla

2
Contenido de la presentación

• Qué es Single Sign-On (SSO)?
• Arquitecturas para un sistema SSO
• Situación actual en la Facultat dInformàtica de
  Barcelona
• Conclusiones

3
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.
4
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

5
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...)

6
Contenido de la presentación

• Qué es Single Sign-On (SSO)?
• Arquitecturas para un sistema SSO
• Situación actual en la Facultat dInformàtica de
  Barcelona
• Conclusiones

7
Arquitecturas SSO Clasificación

• Clasificación de las arquitecturas SSO

Simple
Basada en Tokens
Autentificación Centralizada
Basada en PKIs
SSO
Sincronización de contraseñas
Compleja
Caché en el cliente
Autentificación Múltiple
Caché en el servidor
8
Arquitecturas SSO Solución simple

• Single Sign-On con un único Servidor de
  Autentificación

Primer Sign-On
Servidor de Autentificación
BD de usuarios
Token
ID PW
ID PW
ID PW
Confianza
Validación
Intercambio de Autentificación
Recurso
ID PW
9
Arquitecturas SSO Solución simple

• Etapas en la Solución Simple
• 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.

10
Arquitecturas SSO Solución simple

• Etapas en la Solución Simple
• 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.

11
Arquitecturas SSO Credencial unica

• Single Sign-On basado en el paso de Token

Primer Sign-On
Autoridad de Autentificación Primaria
BD Primaria
Token
ID PW
ID PW
Token Temporal
ID PW
Confianza
Segundo Sign-On transparente usando Token Temporal
Autoridad de Autentificación Secundaria
BD Secundaria
ID PW
12
Arquitecturas SSO Basado en token

• Etapas en la Solución basada en Token
• 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.

13
Arquitecturas SSO Basado en token

• Etapas en la Solución basada en Token
• 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,

14
Arquitecturas SSO Credencial unica

• Single Sign-On basado en el uso de PKI

Registro del Usuario
ID PW
Autoridad de Autentificación Primaria
BD
ID PW
ID PW
Emisión Certificado
Clave Privada
Certificado Usuario
Confianza
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
15
Arquitecturas SSO Basado en PKI

• Etapas en la Solución basada en PKI
• 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.

16
Arquitecturas SSO Pros y Contras
Autentificación Centralizada Autentificación Centralizada 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)
17
Arquitecturas SSO Caché en Cliente

• Single Sign-On con autentificación múltiple y
  basado en caché cliente

Token
Autoridad de Autentificación Primaria
BD Primaria
Primer Sign-On
Token
ID PW
ID PW
PW
Confianza
Caché Cliente Segura
ID PW
ID PW
Segundo Sign-On transparente usando credenciales
almacenadas en cliente
Autoridad de Autentificación Secundaria
BD Secundaria
ID PW
ID PW
18
Arquitecturas SSO Caché en Cliente

• Etapas en la Solución Caché en el Cliente
• 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.

19
Arquitecturas SSO Caché en Cliente

• Etapas en la Solución Caché en el Cliente
• 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,
  

20
Arquitecturas SSO Caché en Servidor

• Single Sign-On con autentificación múltiple y
  basado en caché servidor

Primer Sign-On
Autoridad de Autentificación Primaria
BD Primaria
Token
Peticiones credenciales sucesivas
ID PW
ID PW
Token
Credenciales para AAS1
ID PW
ID PW
Confianza
Segundo Sign-On transparente usando Credenciales
proporcionadas por AAP2
Autoridad de Autentificación Secundaria
BD Secundaria
ID PW
ID PW
1 Autoridad de Autentificación Secundaria2
Autoridad de Autentificación Primaria
21
Arquitecturas SSO Caché en Servidor

• Etapas en la Solución Caché en el Servidor
• 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.

22
Arquitecturas SSO Caché en Servidor

• Etapas en la Solución Caché en el Servidor
• Existe una relación de confianza desde las
  autoridades de autentificación secundarias con la
  primaria.
• Ejemplos
• Tivoli SecureWay SSO, CA Entrust SSO,

23
Arquitecturas SSO Pros y Contras
Autentificación Múltiple Autentificación Múltiple Autentificación Múltiple
Basado en Ventajas Desventajas
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). 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é 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.
24
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

25
Contenido de la presentación

• Qué es Single Sign-On (SSO)?
• Arquitecturas para un sistema SSO
• Situación actual en la Facultat dInformàtica de
  Barcelona
• Conclusiones

26
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)

27
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/POPSSL y Webmail)
  autentificados mediante PAM.

28
Situación actual en la FIB

• Esquema de la situación actual

Replica del Servidor LDAP
Servidor LDAP
SSL
PAM_LDAP
ServidorFTP
SSL
SSL
SSL
SSL
PAM_LDAP
PAM_LDAP
PAM_LDAP
MOD_AUTH_LDAP
Racò WEB Webmail
ServidorIMAP/POP
PC Aules(Samba)
Terminales(Solaris)
29
Situación actual en la FIB

• Descripción de los sistemas que participan en la
  autentificación
• Windows 98, XP y Linux sobre Arquitectura
  x86Autentificación mediante Samba sobre Enos y
  Laika.
• Enos
• Laika
• Terminales Sunray sobre Arquitectura
  Ultra-SPARCAutentificación mediante PAM.
• Moonrey
• Universia
• Ada
• Solfoc

30
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.
• Xino / Xano
• Emilio
• FTP POP/IMAP Webmail fuera del
  RacóAutentificación mediante PAM.
• Emilio
• LDAPServicio de Directorio donde se almacenan
  las credenciales.
• Xino / Xano
• Sanrey

31
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

32
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

33
Implantación - Técnicas

• Desarrollo de una API intermedia
• 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
• 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,

Software
API
Lib. Dinámica
34
Implantación - Técnicas

• Reemplazo de Librerías Dinámicas (DLL/.so)
• Ventajas
• 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.

Software
Lib. Dinámica
35
Implantación - Técnicas

• Reemplazo de las Aplicaciones
• 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.

Software
API
36
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.

37
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.

38
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)

39
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.

40
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)

41
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.

42
Implantación - PKI

• Soluciones PKI para los diferentes servicios
• Soluciones SSH y SFTP
• Secure Shell (Windows, Unix y Linux)
• OpenSSH (Unix , Linux, Windows con Cygwin)
• Soluciones FTP
• GSIFtp (UNIX, Linux y Windows, es un cliente
  java)
• Soluciones Telnet
• No hemos encontrado soluciones que se
  autentifiquen mediante certificados.

43
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.

44
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.

45
Contenido de la presentación

• Qué es Single Sign-On (SSO)?
• Arquitecturas para un sistema SSO
• Situación actual en la Facultat dInformàtica de
  Barcelona
• Conclusiones

46
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.

47
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