Servicio de Autenticación Federado (SAFe)

Transcripción

1 Título de la ponencia: Servicio de Autenticación Federado (SAFe) Información del autor Nombres y apellidos: Luis David Camacho González Grado académico: Estudiante Universitario Cargo: Perfil profesional: Consultor, analista, diseñador y desarrollador de aplicaciones de software. Énfasis en gestión de proyectos y desarrollo de software a la medida. Institución: Universidad Nacional de Colombia Correo electrónico: ldcamachog@unal.edu.co Dirección: Carrera 30 # apto 301 Teléfono celular: Tema desarrollado Proyecto de investigación adyacente de UNBD orientado al manejo y gestión de usuarios en sistemas distribuidos federados. Resumen El servicio de autenticación federado es un esquema que pretende solucionar el problema del manejo de muchos usuarios y contraseñas de una sola persona en ambientes de trabajo; para ello en el ejemplo usado, basado en países, se muestra como un usuario tiene únicamente sus datos inherentes y un nombre de usuario y contraseña que usara para identificarse en cada sistema o aplicación en la cual se quiera implementar. El ejemplo también muestra la forma en la que dos sistemas establecen una comunicación con un contrato de confianza para intercambiar datos y prestar servicios a usuarios de la aplicación origen en la aplicación destino. Texto extenso Introducción El presente documento tiene como finalidad presentar por medio de un ejemplo orientado a sistemas de información bibliográfica el Servicio de Autenticación Federado SAFe, el cual se presenta como solución al problema de tener muchos usuarios y contraseñas en ambientes de trabajo, y en este caso particular para compartir información entre sistemas bibliográficos. Dicha idea e implementación surge como parte del trabajo desarrollado dentro del grupo de investigación UNBD, en el cual actualmente se trabaja en este y otros proyectos similares. La idea original es del estudiante de Ingeniería de Sistemas de la Universidad Nacional de Colombia Milton Molina, la implementación del prototipo existente es del autor de este documento. Qué es SAFe? SAFe es un servicio que debe ser desarrollado sobre aplicaciones tanto ya existentes como en desarrollo el cual permite, bajo el esquema escogido, intercambiar información y prestar servicios de una aplicación a otra sin la necesidad de crear un usuario nuevo para cada persona que contacto@bibliotic.info 1/6

2 necesita dichos servicios y datos; este tipo de situaciones es común en varios entornos de trabajo en los cuales un trabajador requiere consultar información de las diferentes aplicaciones con las que cuenta la empresa para prestar un servicio a los clientes de la misma o simplemente para realizar su trabajo cotidiano. La identificación del problema Es común ver en algunas bibliotecas, principalmente universitarias, que uno de sus servicios mas importantes es la posibilidad de préstamos interbibliotecarios; actualmente para efectuar la búsqueda y correspondiente solicitud de material bibliográfico y de cualquier otro tipo, que pueda obtenerse de una biblioteca, se requiere de un tramite administrativo que no solo resulta en desgaste administrativo y para el usuario. Un ejemplo de como funciona SAFe Para entender de forma sencilla como funciona SAFe vamos a usar un ejemplo sencillo basado en un caso cotidiano y es la nacionalidad y el viajar a otros países; para ello asumamos que toda persona que nace es parte del mundo y el mundo como tal lo sabe, eso significa que hay una lista de personas que pertenecen al mundo, cuando una persona nace obtiene ciertos datos inherentes a si misma y ciertos datos que le corresponden por derecho como un nombre, un apellido, una fecha de nacimiento pero sobre todo una nacionalidad, para ello la nacionalidad depende de que un país sepa que personas del mundo son de su país, finalmente las personas pueden viajar a otros países y para ello requieren ser registrados como personas bienvenidas pero no serán tratadas como personas pertenecientes al país que visitan sino con una serie de condiciones establecidas por el país visitado. Esto es equivalente a que tenemos una lista de personas con sus datos personales y los datos de autenticación del mismo (usuario y contraseña) y cada sistema de información bibliográfica sabe que personas tienen permiso para iniciar sesión y para consumir los respectivos servicios, sin embargo puede que el usuario necesite hacerse de información y/o servicios de otra, para ello no debería pertenecer como usuario a la otra aplicación sino que la aplicación a al que pertenece debería proveerle una forma de comunicación con la otra para obtener la información necesaria, esto lo debe hacer mediante una autenticación remota por medio de la cual el usuario tiene acceso de forma dinámica. SAFe con sistemas de información bibliográfica Planteando un caso hipotético supongamos que existe un sistema de información bibliográfica, dicho sistema es perteneciente a una universidad, por otro lado existe otro sistema similar perteneciente a otra universidad y finalmente un tercer sistema perteneciente a una biblioteca privada. En cada sistema existirá un registro de usuarios los cuales pueden consultar, y solicitar préstamos del correspondiente material. Supongamos entonces que existe también un acuerdo entre dichas entidades de tal forma que la primera universidad puede consultar la colección de la las otras dos, y puede solicitar prestamos de una de ellas digamos la biblioteca privada; el convenio le otorga a la primera universidad un único usuario para realizar dichas consultas y solicitudes, el cual deberán usar todos los posibles usuarios de la primera universidad. Implementando SAFe en dichos sistemas un usuario de la primera universidad pueden consultar y solicitar material haciendo Un proyecto uso de contacto@bibliotic.info 2/6

3 del usuario único asignado a la universidad y sin la necesidad de salir de sus sistema principal, sin embargo el sistema remoto tendrá la información del usuario real que esta consumiendo los sevicios. Funcionamiento de autenticación local Llamaremos autenticación local cuando un usuario trata iniciar sesión en la aplicación en la cual esta registrado, el proceso de autenticación exitosa ocurre de la siguiente manera: El usuario trata de ingresar a la aplicación sin haber iniciado sesión, allí la aplicación solicitara un usuario y contraseña para la autenticación y el inicio de sesión, el usuario ingresa los datos y estos son enviados a la aplicación, ya que esta no conoce usuarios ni contraseñas envía los datos al LDAP a través de un cliente web service, el LDAP valida los datos y retorna los datos personales de la persona, una vez los datos son recibidos por la aplicación esta los valida contra sus datos registrados para saber si la persona existe o no, es decir si es un usuario local, en la aplicación de ser así, inicia la sesión y autoriza el acceso al usuario; en caso contrario la deniega con un mensaje de error. Esto se facilita ya que la aplicación cuenta con dos cosas importantes, la primera es un cliente WS para consumir los servicios publicados por el LDAP y la segunda que conoce los objetos del LDAP por medio de interfaces con una librería. Funcionamiento de una autenticación remota Llamaremos autenticación remota cuando una aplicación se conecta a otra e intercambia datos del usuario para que este sea tratado como usuario local en la segunda aplicación, el proceso de autenticación remota exitoso ocurre de la siguiente manera: Cuando el usuario local ha iniciado una sesión en su aplicación origen, este puede necesitar información o servicios de otra aplicación para ello con solo solicitarla la aplicación iniciará el proceso de autenticación remota para poder consumir sus servicios, para ello usando los datos del usuario actualmente autenticado buscará si tiene un usuario remoto asignado para acceder a la aplicación remota, si es encontrado, establece una comunicación con dicha aplicación por medio de WS, esta información sera valida en la aplicación remota, en este caso un usuario y contraseña, asumiendo que son validos los dos la aplicación remota retornará una respuesta de éxito, una vez recibida la aplicación local procede a enviar los datos de la persona que esta accediendo a la información remotamente, al llegar la aplicación remota cargará al usuario con sus perfiles asignados y completando los datos con los recibidos de la aplicación local, una vez iniciada la sesión y establecida la conexión la aplicación local podrá acceder libremente a la información y servicios que le sea permitido por los permisos y perfiles que le asigne la aplicación remota. En caso de fallo la aplicación local notificará a su usuario que no tiene permisos para ejecutar la acción que desea. Casos especiales Existen por supuesto varios tipos de casos especiales como por ejemplo qué sucede si un usuario que existe en el LDAP esta registrado en dos o mas aplicaciones diferentes y al haber iniciado sesión en una necesita información de otra?, qué perfiles tendrá?, son las sesiones remotas iguales a las sesiones locales?, y algunas otras preguntas similares; para ello la respuesta es que depende de las políticas de las aplicaciones cuando aceptan inicio de sesiones remotas, es decir la aplicación puede hacer una verificación de los datos personales obtenidos para tratar de Un otorgar proyecto los de contacto@bibliotic.info 3/6

4 mismos permisos que tiene localmente o simplemente puede asignar permisos al usuario remoto para las sesiones remotas indiscriminadamente, de la misma forma el manejo de las sesiones depende de la construcción de la aplicación pero de igual forma por seguridad lo recomendable es que sean sesiones diferentes, en resumen no esta definido formalmente de tal forma que para cada aplicación prestadora de servicios es necesario una publicación de un WS y para cada aplicación consumidora de servicios es necesario la creación de un cliente WS, la política es al libre albedrío del diseño. Aspectos importantes Es claro que para este tipo de esquemas el establecimiento de las comunicaciones con intercambio de datos, los cuales pueden llegar a ser sensibles o confidenciales, implican un riesgo de seguridad informática, para mitigar esto es necesario hacer un diseño en el cual los contratos de confianza tengan un sistema de validación constante como un intercambio de tokens, un canal cifrado y preferiblemente que los datos mismos se transmitan de forma cifrada, en lo posible dejar un esquema robusto de validaciones, procurar usar VPN's para la comunicación entre aplicaciones, dejar que las capas de aplicación y comunicación entre aplicaciones no hagan parte de la DMZ y cualquier otra medida de seguridad no sobra. También es natural preguntarse si para implementar SAFe es necesario un LDAP, y la respuesta es NO; aunque el ejemplo por simplicidad y comodidad usa un LDAP en general las aplicaciones tienen su propio esquema de usuarios y datos personales e incluso SAFe puede ser implementado entre aplicaciones completamente separadas sin la necesidad de un servicio de autenticación de un tercero (sin embargo en ambientes locales permite la característica de single sign on), lo único realmente importante para implementar SAFe es que las aplicaciones compartan la información de los usuarios remotos, compartan una estructura común de datos para intercambiar los datos de la persona y una política de intercambio de datos, es decir, las respuestas pueden ser datos para que la aplicación local genere sus propias interfaces dinámicamente, o presentar paginas web con un esquema predefinido de estilos o simplemente retornar paginas web y presentarlas en la aplicación local. Soluciones comerciales similares existentes en el mercado Debido a que este no es un problema nuevo en realidad, algunos proveedores ofrecen actualmente soluciones comerciales para resolver esto, pero estas soluciones comerciales se centran en lograr una característica de single Sign on. Un ejemplo de una aproximación a la idea planteada en este documento, son los servicios de Google ya que es incluso posible, con el mismo juego de cookies cambiar de servicio como pasar de Gmail a Googledocs, Google calendar o incluso blogger sin la necesidad de iniciar sesión de nuevo; por otra parte también es posible interactuar con algunos aspectos de estos servicios desde una sola aplicación particularmente desde Gmail podemos ver videos de Youtube ver algunas cosas de google calendar o ir directamente a documentos de Google docs, pero esto es una aproximación por dos razones importantes la primera es que todos los productos son del mismo proveedor google, y la segunda es que por ese motivo es sencillo, para ellos, hacer integración de sus servicios lo cual no es lo mismo que propone SAFe. A continuación se presenta una lista de enlaces a algunas de estas soluciones: Oracle enterprise single sign on contacto@bibliotic.info 4/6

5 Tivoli - IBM single sign on Novell single sign on Servicio de inicio de sesión único SAML para Google Apps Ipsca SSO Referencias bibliográficas: Wikipedia, Federated identity management, (enero 15 de 2011) Educause, 7 things you should know about Federated Identity Management (enero 15 de 2011) Wikipedia, Identity Management, (enero 15 de 2011) Wikipedia, Credential, (diciembre de 2010) Wikipedia, Common Access Card, (diciembre de 2010) Wikipedia, One-time password, (febrero de 2011) Aqueveque, Carina, Huenchuman, Natalia, Hacking basado en ataques a TCP/IP Jacktu, HACKERS, Seguridad en la Red 2002 Método utilizado Durante el desarrollo del proyecto SIGEPRO, el proyecto principal actualmente en ejecución del grupo de investigación UNBD de la Universidad Nacional de Colombia, hemos topado con una serie de problemas que requieren de una solución no evidente ni convencional para poder lograr el desarrollo planeado de dicho proyecto, es así como nacen algunos proyectos adyacentes entre los cuales SAFe es uno de ellos. contacto@bibliotic.info 5/6

6 Con el fin de atacar el problema de la identificación en sistemas distribuidos y la interacción entre ellos se ideo SAFe como una propuesta para la integración no invasiva entre aplicaciones de diferentes proveedores para lograr los fines requeridos por el proyecto SIGEPRO. Discusión crítica de resultados Como conclusión de este proyecto hemos determinado que una de las formas de hacer una buena gestión de usuarios es con la ayuda de un esquema llamado Single Sign On (SSO) con el cual los usuarios pueden manejar mas eficientemente sus accesos a las diferentes aplicaciones que puedan necesitar para realizar su trabajo, sin embargo un esquema SSO no es suficiente para mejorar el rendimiento de los trabajadores en la interacción con las aplicaciones, por ello SAFe ataca el problema de no tener que salir de la una aplicación para poder consultar y consumir los servicios de otra convirtiendo SSO no solo en una herramienta de gestión de usuarios sino de integración no invasiva de aplicaciones que con solo una definición de usuarios remotos y un juego de políticas, podemos hacer que los usuarios tengan los accesos necesarios sin olvidar las restricciones de manera independiente y con menor gasto en soporte. Conclusiones SSO es una buena solución para la gestión de usuarios pero no es suficiente para hacer una optimización el el trabajo de los mismos. Un esquema de integración de aplicaciones o una aplicación que preste todos los servicios requeridos por una empresa es un gasto no soportable. Un servicio de integración no invasivo de desarrollo propio es de bajo costo, rápido y flexible a las necesidades del cliente. Referencias Oracle enterprise single sign on Tivoli - IBM single sign on Novell single sign on Servicio de inicio de sesión único SAML para Google Apps Ipsca SSO contacto@bibliotic.info 6/6