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

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

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

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

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

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

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

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

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. • Emilio • LDAP:Servicio de Directorio donde se almacenan las credenciales. • Xino / Xano • 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 …

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.

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.

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)

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.

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)

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.

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.

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.

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.

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

Single Sign-On

Single Sign-On

Presentation Transcript

Single Sign-on

Understanding Single Sign-on

Understanding Single Sign-on

Understanding Single Sign-on

SSO : Single Sign On

Enterprise Single Sign On

Single Sign on PowerSchool

Single sign-on

6.3.2012 Single Sign-On

Single Sign-On Offerings

Single Sign On

Single Sign-On (SSO)

Single Sign-On Solutions

SINGLE SIGN-ON

Single sign-on

Mobile Single Sign On

Single Sign-On

Single Sign On

Single sign-on

Single Sign On