1 / 47

Single Sign-On

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

zeki
Download Presentation

Single Sign-On

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 d’Informà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 d’Informàtica de Barcelona • Conclusiones

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

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

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

  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 Token Peticiones credenciales sucesivas BD Primaria 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

  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 d’Informà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/POP+SSL 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 MOD_AUTH_LDAP PAM_LDAP PAM_LDAP PAM_LDAP Racò WEB+ Webmail ServidorIMAP/POP Terminales(Solaris) PC Aules(Samba)

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

  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 • LDAP:Servicio 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 d’Informà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

More Related