Single Sign-On Miquel Trilla

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

¿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. Es un concepto que engloba la posibilidad de autentificación única, la cual permite la introducción de un único usuario y password, para acceder a los recursos que el usuario tiene acceso.

¿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

¿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...) COMENTAR QUE NO SE DEBE CONFUNDIR SSO CON CENTRALIZACION DE LA GESTION DE PASSWORDS, AUNQUE POR ALLI HAY GENTE QUE LO ENTIENDA ASI. NOSOTROS NO! Ayuda a la implantación de políticas de seguridad por el echo de que solo entramos en el sistema por un único sitio. (Es mas fácil memorizar un único password difícil que 5)

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

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 Caché en el cliente Autentificación Múltiple Caché en el servidor

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 Confianza Validación Intercambio de Autentificación Recurso ID | PW

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.

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.

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 Token Temporal ID | PW Confianza Segundo Sign-On transparente usando Token Temporal Autoridad de Autentificación Secundaria BD Secundaria ID | PW

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.

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, …

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

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.

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

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 PW Caché Cliente Segura Confianza ID | PW ID | PW Segundo Sign-On transparente usando credenciales almacenadas en cliente Autoridad de Autentificación Secundaria BD Secundaria ID | PW ID | PW

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.

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, …

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 Token Peticiones credenciales sucesivas BD Primaria 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 Secundaria 2 Autoridad de Autentificación Primaria

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.

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, …

Arquitecturas SSO – Pros y Contras 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 Tiene un impacto importante en el cliente (requiere software extra). Requiere un mecanismo de sincronización de credenciales (puede formar parte del producto SSO). Requiere software extra en el lado del servidor.

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

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

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)

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.

Situación actual en la FIB Esquema de la situación actual: Replica del Servidor LDAP Servidor LDAP SSL 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)

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

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. LDAP: Servicio de Directorio donde se almacenan las credenciales. Sanrey

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 … 9x: Panel de Control de red Netware: GINA (4.x) o NMAS (5.0)

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

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

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

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

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. Problemas: Centralización Tener todos las aplicaciones que necesitan autentificación kerberizadas. Timestamps: relojes sincronizados (de minutos).

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. Problemas: Centralización Tener todos las aplicaciones que necesitan autentificación kerberizadas. Timestamps: relojes sincronizados (de minutos).

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) Problemas: Centralización Tener todos las aplicaciones que necesitan autentificación kerberizadas. Timestamps: relojes sincronizados (de minutos).

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. Problemas: Centralización Tener todos las aplicaciones que necesitan autentificación kerberizadas. Timestamps: relojes sincronizados (de minutos).

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) Posibilidad de conseguir desencriptar los mensajes con un poco de tiempo (poco probable, i en la fib menos pq la gente no se tira horas conectada) -> solucion tiempo de sesion no excesivamente largo

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. Problemas: Centralización Tener todos las aplicaciones que necesitan autentificación kerberizadas. Timestamps: relojes sincronizados (de minutos).

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. Explicar el proyecto globus i su parte de autentificacion SSO (GSI)

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. Problemas: Centralización Tener todos las aplicaciones que necesitan autentificación kerberizadas. Timestamps: relojes sincronizados (de minutos).

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. Problemas: Centralización Tener todos las aplicaciones que necesitan autentificación kerberizadas. Timestamps: relojes sincronizados (de minutos).

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

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.

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