Uso de Kerberos en un entorno WSO2

eEquation Chapter 1 Section 1 Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de la Telecomunicación Dep. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Uso de Kerberos en un entorno WSO2 Sevilla, 2019 Autor: David Barranco Alfonso Tutor: Isabel Román Martínez iii Trabajo de Fin de Grado Grado en Ingeniería de las Tecnologías de la Telecomunicación Uso de Kerberos en un entorno WSO2 Autor: David Barranco Alfonso Tutor: Isabel Roma n Martí nez Profesor colaborador Dep. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 v Trabajo de Fin de Grado: Uso de Kerberos en un entorno WSO2 Autor: David Barranco Alfonso Tutor: Isabel Román Martínez El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2019 El Secretario del Tribunal vii ix Agradecimientos Quisiera empezar este espacio agradeciendo a mi tutora, Isabel, por cada momento que me ha dedicado durante estos años para el desarrollo de este proyecto. Por toda su ayuda y ánimo. Por supuesto agradecer a mi familia, principalmente a mis padres su confianza en mí y su apoyo incondicional. Gracias por toda esa fuerza para realizar este proyecto. Por último, pero no por ello menos importante, a todos los compañeros que he conocido durante estos años en la escuela de ingenieros y a los amigos que me han acompañado durante toda mi vida, sin los cuales no habría llegado hasta aquí. xvii ÍNDICE DE TABLAS Tabla 1 – Información sobre máquinas virtuales 36 Tabla 2 – Características de Carbon de WSO2 IS 45 Tabla 3 - Características de Carbon de WSO2 ESB 57 xix ÍNDICE DE FIGURAS Figura 3-1 Esquema de productos de WSO2 14 Figura 3-2 Esquema funcional del Gestor de Interfaces Públicas 15 Figura 3-3 Esquema funcional del servidor de Integración 16 Figura 3-4 Esquema funcional del Servidor de Identidad 17 Figura 3-5 Esquema de características del Servidor del Internet de Las Cosas 18 Figura 3-6 Esquema de servicios instalables sobre Carbon 19 Figura 3-7 Esquema de tipo de servicios SOA 21 Figura 3-8 Ejemplo de servicio SOA de utilidad 21 Figura 3-9 Ejemplo de servicio SOA de entidad 22 Figura 3-10 Ejemplo de servicio SOA de tarea 22 Figura 3-11 Componentes incluidos en el Servidor de Identidad 23 Figura 3-12 Diagrama de paso de mensajes de Kerberos 27 Figura 4-1 Diagrama de paso de mensajes de Kerberos con productos WSO2 33 Figura 4-2 Creacion de red interna para máquinas virtuales en VirtualBox (I) 34 Figura 4-3 Creación de red interna para máquinas virtuales en VirtualBox (II) 35 Figura 4-4 Importación de máquinas virtuales en VirtualBox 35 Figura 4-5 Ajuste de red interna para máquinas virtuales en VirtualBox 36 Figura 4-6 Menu de reenvío de puertos 37 Figura 4-7 Lista de reenvío de puertos para máquinas virtuales 37 Figura 4-8 Archivo de sistema /etc/hosts 38 Figura 4-9 Descargas del jdk 6u45 39 Figura 4-10 Instalación de jdk 6u45 39 Figura 4-11 Descarga de Carbon 40 Figura 4-12 Descompresión de Carbon en ordenador local 40 Figura 4-13 Inicio de Carbon 41 Figura 4-14 Inicio de sesión en Carbon 42 Figura 4-15 Menú de características de Carbon 42 Figura 4-16 Asistente de configuración de repositorios de características de Carbon 43 Figura 4-17 Instalación de caraterísticas de Carbon 43 Figura 4-18 Menú de gestión de Carbon 46 Figura 4-19 Interfaz de inicio de WSO2 IS 46 Figura 4-20 Activación del KDC en el IS 47 Figura 4-21 Activación del KDC en el IS (2) 48 Figura 4-22 Activación del KDC en el IS (3) 49 Figura 4-23 Inicio del servicio de Kerberos en el IS 49 Figura 4-24 Menú lateral de configuración de Kerberos 50 Figura 4-25 Configuración de ID de servicio de eco 51 Figura 4-26 Creación de ID de servicio de eco 52 Figura 4-27 Menú de configuración de usuarios y roles 52 Figura 4-28 Configuración de usuario y contraseña para el servicio de eco 53 Figura 4-29 Creación de usuario para el servicio de eco 53 Figura 4-30 Interfaz de inicio de WSO2 ESB 57 Figura 4-31 Mensajes de inicio del ESB con dirección de red de administración 59 Figura 4-32 Inicio de sesión en la consola de administración web del servicio 59 Figura 4-33 Interfaz de inicio del ESB 60 Figura 4-34 Menú lateral de configuración de servicios web 61 Figura 4-35 Listado de servicios web incluidos en el ESB 61 Figura 4-36 Consola de administración del servicio web de eco 62 Figura 4-37 Métodos de securización del servicio de eco 63 Figura 4-38 Configuración del ID del servicio de eco 64 Figura 4-39 – Contenido del archivo de configuración de Ant 66 Figura 4-40 – Configuración de políticas de seguridad para el cliente del servicio eco 68 Figura 4-41- Configuración de Kerberos para el cliente del servicio de eco 68 Figura 4-42 – Configuración del contexto del cliente del servicio de eco 69 Figura 4-43 Bucle principal de código del cliente del servicio de eco 70 Figura 4-44 Traza de ejecución del cliente 71 Figura 4-45 Métricas del tiempo de respuesta del servicio de eco 72 Figura 4-46 – Acceso a la configuración de trazas de sistema del IS 73 Figura 4-47 – Cambio de configuración de trazas de sistema en el IS 73 Figura 4-48 – Acceso a la sección de monitorización del IS 74 Figura 4-49 – Búsqueda de usuario en base de datos LDAP 75 Figura 4-50 – Petición de ticket de servicio para el servicio de eco 75 Figura 4-51 – Respuesta de creación de TGS para el servicio de eco 75 Figura 4-52 – Inicio de sesión del cliente contra el servicio de eco 76 Figura 4-53 – Creación de sesión encriptada con el protocolo Kerberos entre cliente y servicio de eco 76 Figura 4-54 – Comprobación de marcas de tiempo de los tickets de Kerberos 77 Figura 4-55 – Creación marcas de tiempo para respuesta del servicio de eco al cliente 77 Figura 4-56 – Añadido de marcas de tiempo a trafico de servicio de eco a cliente 78 Figura 4-57 – Envío de codigo de estado OK del servicio de eco al cliente 79 Figura 4-58 – Diagrama de paso de mensajes entre entidades del caso práctico 79 xxi 1 INTRODUCCIÓN Y OBJETIVO l Máster en ciberseguridad ofertado por la Universidad de Sevilla es una alternativa muy interesante para alumnos que terminan el grado universitario. En él se aporta una visión muy extensa sobre todos los aspectos implicados en la ciber seguridad hoy en día. Actualmente en el módulo dedicado a la securización de servicios y sistemas de información se imparten dos sesiones sobre autenticación y control de acceso muy relacionadas entre sí, pero que presentan un problema de desconexión en los ejercicios de ambas sesiones prácticas. En un esfuerzo por parte del profesorado por mejorar estas sesiones prácticas surge este proyecto, el cual realiza una propuesta de modificación de la sesión de autenticación, para desarrollarla utilizando los componentes y servicios proporcionados por WSO2: • Gestión de autenticación. En esta sesión práctica se realizan diferentes ejercicios sobre un escenario compuesto por 3 equipos en el que se despliega un servicio y se securiza bajo el protocolo de Kerberos. También se utiliza el servicio LDAP como repositorio de los diferentes usuarios y respectivos roles. 1.1. Objetivo El objetivo de este proyecto es el de realizar una propuesta de mejora de esta sesión práctica haciendo uso de las tecnologías que se utilizan en las siguientes sesiones prácticas, creando así un marco común sobre el que desarrollar esta serie de prácticas del Máster de ciberseguridad. Dado que estos ejercicios están basados en el uso del protocolo Kerberos y de la plataforma WSO2 se propone realizar un caso práctico sobre la plataforma WSO2 utilizando el Servidor de Identidad y el Bus de Servicios de Empresa para securizar un servicio haciendo uso del protocolo Kerberos. De este modo, los diferentes equipos que participan en este caso práctico se autentican entre ellos gracias a Kerberos y se le otorga acceso al servicio publicado en la plataforma de WSO2. Gracias a WSO2, la realización de la práctica es sencilla y rápida, de manera que es posible el planteamiento de ejercicios sobre el escenario desarrollado orientados a profundizar los conocimientos enseñados en las clases teóricas. E 11 18 Figura 3-5 Esquema de características del Servidor del Internet de Las Cosas • Internet de las cosas (IOT) [6] Este módulo se centra en la integración de dispositivos móviles, creando una plataforma flexible sobre la que trabajar. Las características de esta solución son: • Gestión automática de dispositivos de iOS, Android y Windows • Control de acceso basado en permisos y monitorización del mismo. • Procesamiento de eventos de protocolos IOT. A modo de ejemplo, esta solución se utiliza actualmente por empresas de telecomunicaciones como Verizon para la gestión de pagos en dispositivos móviles. 19 3.2. Middleware 3.2.1. Definición El término middleware [7] aplica al software que provee una capa de abstracción a las aplicaciones que lo utilizan, enmascarando así la heterogeneidad de las capas subyacentes y reduciendo la complejidad del desarrollo de sistemas distribuidos. La principal característica que tienen todos los tipos de middlewares disponibles hoy en día es la de abstraer funcionalidades de otras capas de software, por lo que hace que el desarrollo de sistemas distribuidos complejos resulte una tarea mucho más asequible. 3.2.2. Carbon Carbon [8] es el middleware que ofrece WSO2 sobre el que se pueden instalar todos los servicios disponibles. Dado que éste es el componente base de la arquitectura de WSO2, está diseñado para ser flexible dependiendo de la infraestructura donde se quiera desplegar. Estas son algunas de sus características: • Diseño escalable (vertical y horizontalmente) en topologías de cluster • Descubrimiento dinámico de servicios • Despliegues con topologías de alta disponibilidad • Autenticación de usuarios basada en roles y atributos Estos son los diferentes servicios disponibles para instalar sobre Carbon: Figura 3-6 Esquema de servicios instalables sobre Carbon 20 3.3. Arquitectura Orientada a Servicios (Service – Oriented Architecture) La Arquitectura Orientada a Servicios (SOA por sus siglas en inglés) [9, 10, 11, 12] es un modelo de arquitectura basado en el paradigma de diseño orientado a servicios. Las soluciones SOA han sido creadas para satisfacer los nuevos objetivos de negocio que han ido surgiendo a medida que el desarollo y arquitectura de las aplicaciones distribuidas ha ido evolucionando. 3.3.1. Diseño y desarrollo de SOA La metodología de modelado y diseño para aplicaciones SOA se conoce como el análisis y diseño orientado a servicios. La arquitectura orientada a servicios, generalmente basada en tecnologías web, es un marco trabajo conceptual que establece una estructura de diseño para el desarrollo e integración de aplicaciones distribuidas. Cuando nos referimos a una arquitectura orientada a servicios se está hablando de un juego de servicios web residentes en una red de computación. Existen diversos estándares relacionados con los servicios web, incluyendo los siguientes: • XML: Siglas en inglés de eXtensible Markup Language. Es un lenguaje de marcas desarrollado por el World Wide Web Consortium utilizado para almacenar datos de forma legible. • HTTP: Protocolo de comunicación que permite las transferencias de información en la World Wide Web. • SOAP: Protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. • REST: Estilo de arquitectura de software para servicios web. Hay que considerar , sin embargo, que un sistema SOA no necesariamente utiliza estos estándares para ser orientado a servicios, aunque lo más habitual es su uso. SOA apuesta por los servicios como base de la arquitectura. Estos diferentes servicios tienen características en común como: reutilización, capacidad de composición (un servicio hace uso de otro servicio o viceversa), estandarización, abstracción, autonomía, etc... 3.3.2. Tipos de Servicios Antes de nada es necesario aclarar que existen diferentes clasificaciones (o modelos) de servicios. La que vamos a exponer a continuación es probablemente la más sencilla y el resto de modelos suelen ser derivados de ésta. Distinguiremos 3 tipos de servicios: • Servicios de utilidad • Servicios de entidad • Servicios de tarea 21 Figura 3-7 Esquema de tipo de servicios SOA 3.3.2.1. Servicios de utilidad Los servicios de utilidad son aquellos que encapsulan una funcionalidad concreta, pudiendo ser válidos para un gran número de casos de uso. Son servicios que no tienen por qué cubrir una necesidad concreta de negocio. Idealmente, estos servicios deben de ser altamente reusables. Figura 3-8 Ejemplo de servicio SOA de utilidad 3.3.2.2. Servicios de entidad Los servicios de entidad son aquellos que están centrados en el contexto de las entidades de negocio. Al contrario que ocurre con los servicios de utilidad, son servicios que están expresamente diseñados para ser aplicados a contextos de negocio, aportando así funcionalidades muy concretas. Evidentemente, estos servicios variarán en función del negocio concreto y las entidades que representa su actividad. A continuación, se muestra un ejemplo: 22 Figura 3-9 Ejemplo de servicio SOA de entidad 3.3.2.3. Servicios de tarea Los servicios de tarea son aquellos que engloban un proceso de negocio apoyándose (normalmente) en servicios de más bajo nivel como los servicios de utilidad o de entidad. Suelen implementar un flujo de trabajo entre los servicios que subyacen a este. Una característica importante de estos servicios es que no suelen ser servicios con un grado de reutilización tan alto como los servicios de entidad o utilidad. Es muy importante tener una buena base de servicios de entidad y utilidad sobre los que apoyar los servicios de tarea, pudiendo así ofrecer una respuesta al cambio de forma ágil. Figura 3-10 Ejemplo de servicio SOA de tarea Como se ve en la imagen, este servicio concreto ha de estar apoyado en diferentes servicios de utilidad, en concreto, en las entidades de negocio que intervienen en el proceso y en algún servicio de utilidad (como el de enviar un correo electrónico). 3.3.2.4. Beneficios Algunos de los principales beneficios que aporta SOA son: • Aplicaciones flexibles, reutilizables y adaptables al cambio • Reducción de costes 23 Figura 3-11 Componentes incluidos en el Servidor de Identidad • Mejora en los tiempos de realización de cambios en procesos • Facilidad para evolucionar a modelos de negocios basados en externalización 3.3.2.5. Diferencias con otras arquitecturas Al contrario que las arquitecturas orientadas a objetos, las SOA están formadas por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma en la que estén desplegados y del lenguaje de programación (por ejemplo, WSDL). Con esta arquitectura se pretende que los componentes software desarrollados sean muy reutilizables, ya que la interfaz se diseña en base a estándares de la industria. 3.4. WSO2 Servidor de Identidad – Identity Server Junto con el Bus de Servicios de Empresa, el cual se introduce en el apartado 3.5, el servidor de identidad ha sido utilizado en el despliegue del caso práctico del proyecto. Actualmente, WSO2 ofrece soluciones para el despliegue del servicio sobre servidores, plataformas de cloud y contenedores de microservicios. El servidor de identidad (a partir de ahora IS) es completamente de código libre y está desarrollado bajo la licencia de Apache 2.0. La frecuencia de actualizaciones del servidor es mensual. El código fuente del mismo puede encontrarse aquí: https://github.com/wso2/product-is Las caracterísiticas más destacables de este producto son: 24 • Proporciona una interfaz (API) para la integración de las caracterísiticas de gestión de identidad en cualquier aplicación. Pensado para entornos SOA, optimizado para la integración con otras soluciones WSO2. • Permite Single Sign-On (SSO) basado en OpenID, SAML2, y Kerberos • Proporciona una aplicación web para la gestión de usuarios, perfiles, claves y proveedores de servicios • Incluye repositorios de información de usuarios (LDAP) y puede ser configurado para utilizar otros (Microsoft Active Directory) • Facilita la gestión de perfiles de usuarios, con múltiples perfiles por usuario • Permite bloqueo de cuentas tras un número determinados de intentos fallidos de acceso • Políticas para validación de claves • Permite realizar un acceso a interfaces públicas basado en roles (RBAC – Role Based Access Control) y atributos (ABAC – Atribute Based Access Control). • Control de acceso via XACML, WS-Trust, OpenID, y gestión de solicitudes • El servidor de identidad puede ser configurado como un punto de administracion de políticas, el cual permite: o Establecer políticas de grano fino via XACML o Editar políticas por medio de una interfaz gráfica o Verificar las políticas creadas mediante herramientas o Soportar múltiples puntos de información de políticas (PIP) o Distribuir políticas a distintos puntos de decisión de políticas (PDP) • El servidor de identidad tambien puede ser configurado como un punto de decision de políticas (PDP), el cual permite: o Almacenar en memorias de caché las decisiones y los atributos de políticas o Notificar de actualizaciones de políticas • Include un punto de administracion de políticas para gestionar diferentes puntos de decisión de políticas 3.5. WSO2 Bus de Servicios de Empresa – Enterprise Service Bus Por último, pero no por ello menos importante, es el turno de hablar del Bus de Servicios de Empresa [13]. Este producto ofrece capacidades de integración de datos sin necesidad de desarrollar aplicaciones específicas para ello. Básicamente, lo que integra este servicio es un motor de mensajería configurable, haciendo muy sencilla la integración entre todo tipo de sistemas, sin necesidad de añadir más servidores destinados a la integración de datos. Además, al igual que la mayoría de productos de WSO2, incluye la monitorización de los mensajes enviados, dando la posibilidad de monitorizar de una manera muy clara las comunicaciones de redes internas. Referenciando algunas de sus características: • Más de 160 tipos de conectores, incluyendo categorías de pagos online, redes sociales o sistemas legados. • Transporte: HTTP/S, webSocket, POP, IMAP, SMTP y más. 25 • Capacidad para utilizar servicios de almacenaje de datos, bases de datos relacionales u hojas de cálculo de Google. • Capacidad de transformar peticiones de un estándar a otro para realizar la integración entre distintos sistemas. • Alta disponibilidad, escalabilidad, rendimiento y estabilidad. 3.6. Protocolo Kerberos 3.6.1. Definición Kerberos [14, 15, 16] es un protocolo de red creado por el MIT (Instituto Tecnológico de Massachusetts) que utiliza criptografía de claves simétricas para autenticar usuarios contra servicios de red, evitando así tener que enviar las contraseñas de los mismos a traves de una red insegura de datos. 3.6.2. Motivación Kerberos fue diseñado para proteger los servicios de red del proyecto Athena [17], el cual fue un proyecto de cooperación del MIT junto con otras empresas para crear un entorno de computación distribuida. Kerberos está basado en el protocolo Needham-Schroeder, uno de los primeros protocolos diseñados que utilizaban claves simétricas para compartir datos por una red de datos insegura. 3.6.3. Conceptos importantes En este apartado se comentan los detalles más importantes para un correcto entendimiento del funcionamiento del protocolo Kerberos. Un caso real en el que se detalla el paso de mensajes entre las distintas entidades se presenta al final de este capitulo. En un escenario clásico en el que Kerberos securiza el acceso a un servicio, los elementos involucrados en la comunicación son los siguientes: • El cliente es el agente de usuario que accederá al servicio web de una forma segura. • El Servidor, que contiene el servicio al que el usuario desea acceder. • El Centro De Distribución de Claves (KDC a partir de ahora). Es lo que se suele conocer tambien como el controlador del dominio. Dentro de este servidor se ejecuta el proceso principal de Kerberos, el cual provee los dos principales servicios de Kerberos: • Servidor de Autenticación (AS a partir de ahora). • Servidor de Reparto de Tickets (TGS a partir de ahora). Es clave detallar que Kerberos trabaja con dominios o "reinos". Una vez instalamos Kerberos, en la primera configuración de este, deberemos configurar el dominio de red donde trabajará. Existen a su vez configuraciones inter-dominio más complejas, las cuales no se abarcan en el desarrollo de este trabajo. Otros puntos importantes a destacar: • Con cada interacción, el cliente recibe dos mensajes. Uno que puede desencriptar y otro que no. • El servicio al que quiere acceder el cliente nunca se comunica directamente con el KDC. • A cada contraseña almacenada en el KDC, se le realiza un hash y se le añade una parte generada aleatoriamente por el KDC. Esta parte aleatoria se conoce como “salt”. • El KDC en sí mismo está encriptado con una contraseña maestra para añadir otro punto de seguridad a la hora de obtener claves de la base de datos donde almacena las contraseñas de los usuarios • Todas las claves que se utilizan en el paso de mensajes de una entidad a otra son encriptadas 26 siguiendo los algoritmos DES-CBD-MD5, con una longitud de clave de 56 caracteres. Estos son los que por defecto Kerberos debe soportar, aunque se puede configurar con otro tipo de algoritmos como RC4-HMAC, en los cuales la longitud de la clave pasa a ser 128 caracteres. • Kerberos utiliza principales para identificar de forma unívoca a usuarios o servicios autenticados mediante el protocolo de Kerberos. Un principal sigue el siguiente formato: {Nombre de usuario/servicio} / {instancia} / {Dominio de Kerberos} Donde el nombre será un identificador único que represente a ese usuario o servicio, la instancia es un identificador de la máquina donde está alojado el servicio o donde se encuentra el usuario y el dominio es el reino de Kerberos al que el usuario o servicio pertenece. Es importante mencionar que cada principal tiene asociado una contraseña, ya sea para un usuario o para un servicio. Durante el desarrollo del caso práctico será necesario crear un identificador del servicio que el cliente utilizará como identificador del servicio al que quiere conectarse. 3.6.4. Ventajas de Kerberos Los servicios de red más convencionales usan esquemas de autenticación basados en contraseñas. Tales esquemas requieren que los usuarios se autentiquen en servicios proporcionando sus credenciales de usuario, que normalmente viajan por la red sin estar encriptadas. Además, con estos es posible conocer si el usuario que está accediendo al servicio es legítimo. Por lo tanto, el primer objetivo de Kerberos es el de eliminar la transmisión a través de la red de información de autenticación sin cifrar. Basado en el uso de claves públicas/privadas para compartir claves simétricas Kerberos consigue establecer una comunicación segura. 3.6.5. Desventajas de Kerberos A pesar de que Kerberos elimina una amenaza de seguridad común, puede ser difícil de implementar por una variedad de razones: • La migración de contraseñas de usuarios desde una base de datos de contraseñas estándar UNIX a una base de datos de contraseñas Kerberos puede ser tediosa y no hay un mecanismo rápido para realizar esta tarea. • Kerberos supone que cada usuario es de confianza pero que está utilizando una máquina no fiable en una red no fiable. Su principal objetivo es el de prevenir que las contraseñas no encriptadas se envíen a través de la red. Sin embargo, si cualquier otro usuario no autorizado, tiene acceso a la máquina que emite los tickets usados para la autenticación (Centro de Distribución de Claves, KDC), el sistema completo de Kerberos está en riesgo. • Para que una aplicación use Kerberos, esta debe estar diseñada y programada para realizar las llamadas a los distintos servicios de Kerberos. Por lo tanto, adaptar una aplicación al uso de Kerberos es una tarea a considerar, en términos de tiempo de desarrollo. 27 3.6.6. Paso de mensajes Sin más, vamos a ver un ejemplo de como sería una comunicación entre cliente y servidor utilizando Kerberos, basándonos en el esquema antes propuesto. En siguientes capítulos se verá como este esquema cambia al introducir en él los productos de WSO2. Figura 3-12 Diagrama de paso de mensajes de Kerberos Petición TGT para acceder al TGS Cuando el cliente quiere acceder al servicio web, este introduce sus credenciales en el equipo cliente. Es requisito necesario que previamente ese usuario haya sido creado en el sistema (AS) por un administrador. Una vez el usuario inicia sesión para acceder al servicio, se envía un mensaje al servidor de autenticación (AS) en texto plano pidiendo el Ticket-Granting Ticket, o TGT. Este mensaje del cliente en texto plano incluye: • El nombre/ID del cliente • El nombre/ID del servicio al que solicita acceso (En este caso, el cliente solicita acceso al TGS, que es el que le dará acceso al servicio en el que está interesado) • La dirección de red del cliente • El tiempo de vida válido para el TGT Envío de datos TGT y datos de sesión con el TGS Una vez el AS recibe esta petición, comprueba si el usuario está en la base de datos del KDC. Este sólo comprueba si el usuario existe, no comprueba nada relacionado con las credenciales del mismo. Si durante la comprobación no ha habido ningún error (como que el usuario no se haya encontrado), el AS genera una clave de la sesión para usarla entre el cliente y el TGS. 34 7. A partir de aquí comienza la comunicación HTTP encriptada entre los dos extremos. 4.2. Virtualbox Para el desarrollo de este proyecto se utilizan máquinas virtuales con el sistema operativo Ubuntu, en la version 16.04. La elección de este sistema operativo se ha basado en la disponibilidad de los paquetes de Kerberos, siendo para los alumnos más sencilla la instalación de estos paquetes que en otras distribuciones Unix. El software de virtualización escogido para el desarrollo de este caso práctico ha sido Virtualbox. Su página de descarga es: https://www.virtualbox.org/wiki/Downloads Antes de proceder a ejecutar las máquinas virtuales y comenzar a trabajar con ellas, es necesario definir una red privada en Virtualbox. Para ello, es necesario ir a las opciones de configuración de Virtualbox y elegir sobre la pestaña de redes: Figura 4-2 Creacion de red interna para máquinas virtuales en VirtualBox (I) Ahora, es necesario elegir la opción con el símbolo "+" y crear una red NAT. Con esto, se está definiendo una subred privada la cual utilizarán las máquinas virtuales para obtener su dirección de red, y así conseguir conectividad entre ellas. La configuración de esta subred privada se detalla en la siguiente imagen: 35 Figura 4-3 Creación de red interna para máquinas virtuales en VirtualBox (II) A la hora de instalar las máquinas virtuales en Virtualbox solo será necesario seleccionar el archivo con formato .ova. Acto seguido, el asistente de Virtualbox se ejecutará: Figura 4-4 Importación de máquinas virtuales en VirtualBox Seleccionando Importar, habrá terminado el proceso de instalación de la máquina virtual. Una vez hecho este paso, es necesario configurar en cada una de las máquinas virtuales la subred que se ha creado en pasos anteriores, por lo que será necesario hacer clic derecho sobre la máquina virtual en la interfaz de Virtualbox y 36 buscar las opciones relacionadas con la red. Figura 4-5 Ajuste de red interna para máquinas virtuales en VirtualBox Como se aprecia en la imagen, es necesario seleccionar una red NAT y escoger el nombre creado anteriormente. Una vez modificado esto en las tres máquinas virtuales se puede comenzar a trabajar con ellas. 4.2.1. Información sobre máquinas virtuales A continuación se adjunta la información sobre los usuarios y contraseñas de los distintos usuarios de las máquinas virtuales: Máquina virtual Información Dirección de red WSO2 IS Usuario: wso2is – Contraseña: wso2is 192.168.1.4 WSO2 ESB Usuario: wso2esb – Contraseña: wso2esb 192.168.1.6 Cliente Usuario: client – Contraseña: client 192.168.1.5 Tabla 1 – Información sobre máquinas virtuales Dado que es posible ejecutar este caso práctico dentro de un solo ordenador usando las diferentes máquinas virtuales, se adjunta tambien una lista de reenvío de puertos entre la máquina que ejecuta todas las máquinas virtuales y las propias máquinas virtuales, para que sea mas sencillo acceder a los diferentes servicios que se 37 lancen dentro de ellas. Para configurar esta lista de puertos que seran reenviados entre las diferentes máquinas es necesario acceder al menú donde se configuró la red interna de las máquinas virtuales y utilizar la opcion de “Port Forwarding”: Figura 4-6 Menu de reenvío de puertos Figura 4-7 Lista de reenvío de puertos para máquinas virtuales 4.3. Configuración de direcciones de red de las máquinas virtuales Ya que para este proyecto no se ha utilizado un servidor DNS interno a la red local por simplicidad del escenario, es necesario modificar el archivo /etc/hosts de todas las entidades del escenario. Este archivo es usado por el sistema operativo para guardar la correspondencia entre dominios de internet y direcciones IP. Este es uno de los diferentes métodos que usa el sistema operativo para resolver nombres de dominios. Si queremos desplegar una configuración distribuida debemos configurar los archivos de estas máquinas y añadir las siguientes líneas. • IP del servidor IS y alias • IP del cliente y alias • IP del ESB y alias El resultado final debe ser: 38 Figura 4-8 Archivo de sistema /etc/hosts A modo de ejemplo, en la imagen anterior se ha configurado al servidor de identidad con el alias wso2is. 4.4. Máquinas virtuales de WSO2 Este apartado está dedicado a la preparación de las máquinas virtuales sobre las que se instalarán los productos de WSO2, ya sea el IS o el ESB 4.4.1 Requisitos de software a instalar El software necesario para la preparación de esta máquina virtual es el siguiente: • Java Development Kit 1.6u45 • Carbon - Versión 3.2.3 4.4.1.1. Java Development Kit 1.6 Java Development Kit (JDK) es el kit de desarrollo de Java, el cual provee de las herramientas necesarias para para el desarrollo de software en Java. El IS, el ESB y el cliente desarrollado en Java hacen uso de él, por lo que será necesario instalarlo en las tres máquinas virtuales con las que vamos a trabajar. La descarga del JDK 1.6 u 45 se realiza desde la siguiente página: http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads- javase6-419409.html#jdk-6u45-oth-JPR 39 Figura 4-9 Descargas del jdk 6u45 Dependiendo de la arquitectura del procesador de la máquina en la que se instale el Java Development Kit (JDK) se escogerá entre una arquitectura u otra. Como se va a trabajar con una distribución de ubuntu, es necesario elegir el formato .bin para la descarga. Una vez descargado se dan permisos de ejecución con el comando: chmod +x jdk-6u45-linux-x64.bin Y ejecutamos con la orden: ./jdk-6u45-linux-x64.bin El ejecutable extraerá una carpeta en el directorio donde se haya ejecutado el comando con las herramientas que se necesitan. Esta carpeta debemos copiarla al directorio donde se almacenan las distintas versiones de la máquina virtual de Java. La ruta es: /usr/lib/jvm/. Para copiar la carpeta al nuevo directorio se debe ejecutar: cp -rf jdk1.6.0_45/ /usr/lib/jvm/ Hecho esto, si comprobamos el directorio /usr/lib/jvm/ se comprueba que está ahí la carpeta: Figura 4-10 Instalación de jdk 6u45 Ahora debemos configurar la variable de entorno JAVA_HOME con la dirección a esa carpeta. Cuando el IS y el ESB se inicien comprobarán el valor de esa variable. Si apunta a una máquina virtual de java podrán iniciarse correctamente, si no, obtendremos un fallo con un mensaje de información sobre la configuración de esa 40 variable. Para configurar la variable debemos introducir: export JAVA_HOME=/usr/lib/jvm/jdk1.6.0_45/ Una vez hecho esto, la máquina virtual de Java estará correctamente configurada. 4.4.1.2. Carbon Al igual que con todos los productos de WSO2, hay dos formas de instalarlos: • Descargar Carbon e instalar todas las características del producto que se desea instalar (en este caso el servidor de identidad). • Descargando Carbon configurado con todas las caracterísiticas del producto que se busca configuradas. Los binarios de Carbon se puede encontrar en el siguiente enlace: http://wso2.com/more-downloads/carbon/ En este caso se utilizará la versión 3.2.2: Figura 4-11 Descarga de Carbon Pulsando sobre Binary hará que comience la descarga automática de Carbon, el cual estará comprimido en formato .zip. Una vez descargardo y descomprimido tendremos la carpeta que contiene el servidor de Carbon. Figura 4-12 Descompresión de Carbon en ordenador local 41 La estructura de carpetas de Carbon (y de todos los productos de WSO2) es la siguiente: wso2carbon-3.2.2 ├── INSTALL.txt ├── LICENSE.txt ├── README.txt ├── bin ├── dbscripts ├── lib ├── release-notes.html ├── repository └── tmp Una breve explicación sobre los distintos directorios: • bin/ : Todos los binarios y archivos de código necesarios para iniciar el servidor de Carbon. • dbscripts/ : Archivos de código que crean las distintas bases de datos que Carbon trae por defecto. • lib/ : Librerias de sistema. • repository/ : Archivos de configuración de Carbon. • tmp/ : Archivos temporales utilizados durante la ejecución de Carbon. Una vez Carbon esté instalado y el JDK esté correctamente configurado, se procede a instalar las características de Carbon para conseguir las funcionalidades del IS. Para ello, se debe de iniciar Carbon siguiendo estos pasos: • Se define la variable CARBON_HOME para mostrar la ruta con la que estemos trabajando. Esta ruta puede variar dependiendo de donde se hayan descargado los binarios del servidor. En este caso la variable CARBON_HOME está configurada con: export CARBON_HOME= /home/$(whoami)/Downloads/wso2carbon-3.2.2/ Para iniciar Carbon se ejecuta el siguiente comando: chmod +x $CARBON_HOME/bin/wso2server.sh && sh $CARBON_HOME/bin/wso2server.sh Y aparecerán en la consola trazas del inicio del servidor de gestión de Carbon: Una vez el servidor se haya iniciado correctamente, mostará la dirección de red en la que el servidor está escuchando para poder acceder a ella y administrarlo. Figura 4-13 Inicio de Carbon 42 Si se accede a la dirección y puerto mostrados en la consola aparecerá en el navegador web la interfaz de gestión de Carbon, donde se muestra un formulario para ingersar en la consola de gestión. El usuario y contraseña por defecto es admin y admin. Una vez dentro de la consola de administración se utilizará el menú lateral para acceder a la configuración de las característica instaladas en el servidor: Una vez se acceda al menú de Características (Features) encontraremos la interfaz para añadir un repositorio de caracterísiticas del servidor. Este repositorio puede ser local o estar albergado en algún servidor público de Internet. En este caso se utiliza el repositorio de WSO2 de la versión 3.2.2. La dirección de este servidor es: http://product-dist.wso2.com/p2/carbon/releases/3.2.2/ Figura 4-14 Inicio de sesión en Carbon Figura 4-15 Menú de características de Carbon 43 Para configurar el repositorio se accede pulsando el botón de Añadir Repositorio (Add Repository) y se rellena la información necesaria sobre este: Se añade el repositorio pulsando sobre el botón Añadir (Add). Una vez añadido, se puede comenzar a buscar características del servidor pulsando sobre el botón Encontrar Características (Find features). Por defecto, si no se rellena ningún parámetro de búsqueda en el campo del formulario destinado a ello, se mostrarán todas las características disponibles para instalar: Figura 4-17 Instalación de caraterísticas de Carbon Figura 4-16 Asistente de configuración de repositorios de características de Carbon 50 5.5.1.4 Configuración de principal del servicio eco en el IS Como se mencionó en apartados teóricos anteriores, Kerberos utiliza principales para identificar de manera unívoca a usuarios y servicios dentro de un dominio de Kerberos. Estos principales siguen el formato: {Nombre de usuario/servicio} / {instancia} / {Dominio de Kerberos} Donde se configura el identificador del servicio, máquina donde ese servicio o usuario se encuentra y el dominio de Kerberos donde se encuentra ese servicio o usuario. En este apartado se procede a la creación de un principal para el servicio de eco, de manera que pueda ser identificado en el dominio de Kerberos. Si se accede a la consola de gestión del IS, recordando que por defecto estará en el puerto 9443 de la máquina en la que se haya instalado, aparecerá la interfaz de usuario de la consola. En esta interfaz de gestión es necesario iniciar sesión con usuario y contraseña admin, como ya se mostró en un apartado anterior. El valor por defecto de estas credenciales aparece en el archivo user-mgt.xml, ya modificado. Una vez se inicia sesión en el sistema se puede apreciar en la interfaz principal de la consola de gestión la información sobre el servidor de identidad. En el menú lateral se dispone de una sección de administración de los diferentes usuarios y distintas opciones que dispone el servidor de identidad. El siguiente paso es crear el Service Principal. En el menú lateral de la consola de gestión se accede a la opción “Configure”. Dentro de esa opción accedemos a la de “Kerberos KDC / Service Principals” : Figura 4-24 Menú lateral de configuración de Kerberos Y se elige la opcion Add a new service principal: 51 WSO2 tiene por defecto configurado el dominio de Kerberos, que por defecto es WSO2.ORG, en sus archivos de configuración, por lo que no es necesario añadir el diminio de Keberos. Como se mencionó anteriormente, es necesario configurar un id único de servicio y la máquina en la que el servicio está alojado. Dado que el servicio de eco se encuentra alojado en el ESB, esta es la configuración que se va a utilizar: • Service Name: eco/wso2esb • Description: Service principal for ESB (Id del servicio representando al ESB) • Contraseña: qazqaz Se ha utilizado wsoesb como alias del ESB. Este alias fue configurado anteriormente en el archivo /etc/hosts. Figura 4-25 Configuración de ID de servicio de eco 52 Cuando se finalice la creación del id del servicio debería aparecer en la interfaz de los id de servicio: Figura 4-26 Creación de ID de servicio de eco Una vez creado el identificador del servicio de eco es necesario crear el usuario que va a acceder a este servicio. En el esquema de la sección anterior el cliente envía al servidor de identidad sus credenciales de usuario, las cuales se crearán a continuación. Para crear este usuario se debe pulsar en “Users and Roles” → ”Users”: Figura 4-27 Menú de configuración de usuarios y roles Y utilizamos la opción de crear un nuevo usuario siguiendo la interfaz web: 53 Figura 4-28 Configuración de usuario y contraseña para el servicio de eco Los datos usados en la realización de este caso práctico son: Usuario: dbaus Contraseña: wsxwsx Una vez creado este usuario aparecerá en la sección de usuarios: Figura 4-29 Creación de usuario para el servicio de eco En este punto el IS estaría preparado para ser utilizado como KDC en este caso práctico. Se dispone de un service principal que se utilizará posteriormente para la autenticación con el servicio de eco y un usuario que utilizará el alumno para autenticarse contra el IS. 54 4.6. Máquina virtual ESB Es importante mencionar que en esta máquina virtual es donde se encontrará alojado el servicio de eco. Este servicio es desplegado a través del ESB, por lo que es necesario configurar el ESB para después poder configurar el servicio de eco. Ya que la instalación de Carbon ha sido explicada en apartados anteriores, se muestra a continuación la lista de paquetes que necesitan ser instalados en Carbon para configurar el ESB: COMPONENTE VERSION Application Management 3.2.2 Axis2 Transport HTTP Pass-through 1.0.2 Carbon 3.2.3 CSG Agent 3.2.3 Datasource Management 3.2.3 Deployment Synchronizer 3.2.2 EC2-Client Module 3.2.0 Endpoint Management 3.2.3 ESB - Samples Features 4.0.3 ESB - Styles Features 4.0.3 Event 3.2.1 FIX Transport Core 3.2.0 JMS Transport Core 3.2.0 Local entry Management 3.2.2 Logging Management 3.2.2 Mail Transport Core 3.2.0 Mediation Initializer 3.2.3 Mediation Statistics 3.2.3 Mediation Tracer 3.2.0 Mediators 3.2.3 55 Message Flows 3.2.0 Message Processor Management 3.2.0 Message Relay Core 3.2.3 Message Store Management 3.2.3 Mex Module 3.2.0 NHTTP GET Request Processor 3.2.3 OAuth Mediation 3.2.1 Priority Mediation Management 3.2.2 Proxy Services 3.2.3 Registry Associations/Dependencies 3.2.3 Registry Community Features 3.2.3 Registry Core 3.2.3 Registry Resource Properties 3.2.2 Registry UI Menu 3.2.0 Reporting Core 3.2.3 Reporting UI 3.2.2 Rest API 3.2.3 Rule Drools Engine 3.2.0 Rule JSR94 Engine 3.2.0 Rule Mediation 3.2.0 Scheduled Tasks 3.2.0 Security Management 3.2.3 Sequence Tempalates Management 3.2.0 Sequences Management 3.2.2 Service Management 3.2.3 56 Smooks Mediator Aggregated 3.2.0 SOAP Tracer 3.2.0 Statistics 3.2.2 Stratos - Load Balance Agent UI 1.1.0 STS 3.2.2 SVN Based Deployment Synchronizer 3.2.2 Synapse 2.1.0.wso2v5 Synapse Application Deployer 3.2.0 Synapse Application Management 3.2.0 Synapse Artifact Uploader 3.2.2 Synapse Config Admin 3.2.3 Synapse FIX Transport 2.1.0.wso2v5 Synapse Nhttp Transport 2.1.0.wso2v5 Synapse VFS Transport 2.1.0.wso2v5 Synapse VFS Transport’s SMB supports 2.1.0.wso2v2 Transport Management 3.2.2 Transport Statistics 3.2.0 Tryit 3.2.2 VFS Transport Management 3.2.0 WS-Discovery Core 3.2.0 WS-Discovery Management UI 3.2.0 WSDL Tools 3.2.0 XACML Mediation 3.2.2 Xfer Module 3.2.0 XKMS Management 3.2.0 57 Tabla 3 - Características de Carbon de WSO2 ESB Una vez instaladas todas estas características es necesario seguir el mismo proceso que en el capítulo anterior y ejecutar un Graceful Restart para finalizar la instalación de todas las caracterísitcas de Carbon. Una vez reiniciado, tendremos la interfaz de ESB: Figura 4-30 Interfaz de inicio de WSO2 ESB 4.6.1. Configuración del ESB y servicio de eco Esta sección está dedicada a la configuración del ESB y del servicio de eco. Al igual que en la sección dedicada al IS, para trabajar con los distintos directorios definiremos una variable de entorno llamada $ESB_HOME, la cual contiene la ruta hasta el de la instalación del ESB: $ESB_HOME=/home/$(whoami)/esb/wso2carbon-3.2.3/ 4.6.1.1. Archivo de configuración – krb5.conf Como se va a securizar el servicio de eco con Kerberos es necesario crear un archivo de configuración de Kerberos para el ESB, ya que por defecto este servidor no tiene información del KDC. El ESB encontrará en este archivo la información sobre el servidor de tickets de Kerberos (direccion de red, puerto, dominio de Kerberos…). Este archivo de configuración de Kerberos se ha de llamar krb5.conf y debe tener el siguiente contenido: [libdefaults] default_realm = WSO2.ORG default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 allow_weak_crypto = true [realms] WSO2.ORG = { kdc = wso2is:8000 58 } [domain_realm] .wso2.org = WSO2.ORG wso2.org = WSO2.ORG Dentro de este archivo pueden diferenciarse dos bloques de configuración: • Opciones por defecto para la librería de Kerberos: Donde se configura el reino de Kerberos por defecto que se va a utilizar, los algoritmos de encriptación para los tickets de Kerberos. Dado que en las versiones más recientes de Kerberos la lista de algoritmos ha sido marcada como insegura, es necesario incluir el parámetro allow_weak_crypto para que Kerberos la admita. • Reinos de Kerberos: En este bloque se configura donde está el centro de distribución de claves que el reino de Kerberos WSO2.ORG va a utilizar. En este caso, contiene el alias de la dirección IP del IS. Este archivo ha de colocarse en la siguiente ruta: $ESB_HOME/repository/conf/ Nota: Como se ve en el código, se sigue utilizando is como la dirección de red del IS. Es necesario modificar el archivo /etc/hosts como se hizo anteriormente en la máquina virtual del ESB. 4.6.1.2. Archivo de configuración – Jaas.conf Este archivo configura el servicio de autenticación y autorización de Java (Java Authentication and Authorization Service - JAAS) [18]. Este servicio es la implementación del módulo de autenticación de Linux, pero en Java. Es utilizado por el ESB para gestionar la autenticación de un cliente contra el servicio de eco haciendo uso del módulo de Kerberos del servicio JAAS. Para configurar el servicio de autenticación de Java, es necesario crear un archivo llamado jaas.conf con el siguiente contenido: Server { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=false storeKey=true useTicketCache=false Initiator=false principal=”eco/wso2esb”; }; Esta configuración hace que el ESB no utilice una caché para guardar los tickets de Kerberos ni los principales de los servicios. Es por eso que el principal del servicio de eco se guarda en este archivo. Y colocarlo en la ruta: $ESB_HOME/repository/conf Aquí es importante mencionar que el parámetro “principal” de este archivo debe contener el mismo identificador que se utilizó en el IS. 4.6.1.4. Inicio del ESB Para arrancar el servidor hay que acceder a la carpeta: 59 $ESB_HOME/bin/ Y buscar el archivo llamado wso2server.sh. Al igual que para el IS es necesario aplicar permisos de ejecución ahora se debe hacer lo mismo: chmod +x wso2server.sh Acto seguido, se ejecuta el archivo de código encargado del inicio del servidor: ./wso2server.sh Aparecerá por consola la información relativa al inicio del servidor. Cuando este termine el inicio aparecerá entre las trazas de ejecución el siguiente mensaje con la dirección de red de la consola de gestión: Figura 4-31 Mensajes de inicio del ESB con dirección de red de administración 4.6.1.5. Consola de administración web Si se accede a la dirección mostrada en la información de inicio del servidor encontraremos la interfaz de la consola de administración: Figura 4-32 Inicio de sesión en la consola de administración web del servicio Para iniciar sesión en el sistema utilizaremos las mismas credenciales que para el IS por defecto. Usuario y contraseña admin. 66 4.7.1.1. Archivo de configuración de cliente – build.xml Este archivo es utilizado por la herramienta Ant. En él se pueden configurar los aspectos de compilación del cliente, por lo que la compilación y ejecución resulta mucho más sencilla: Figura 4-39 – Contenido del archivo de configuración de Ant Este archivo ya viene configurado por defecto, por lo que no es necesario realizar ninguna configuración sobre el. 4.7.1.2. Archivo de configuración de cliente – krb5.conf Será necesario de nuevo realizar la configuración de Kerberos. Se creará otro archivo de configuración en la siguiente ruta: /home/$(whoami)/clienteKerberos/org.wso2.identity.esb.kerberos/repo/conf El contenido de este archivo debe ser el siguiente: [libdefaults] default_realm = WSO2.ORG default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1 allow_weak_crypto = true [realms] WSO2.ORG = { kdc = wso2is:8000 } 67 Dentro de este archivo pueden diferenciarse dos bloques de configuración: • Opciones por defecto para la librería de Kerberos: Donde se configura el reino de Kerberos por defecto que se va a utilizar, los algoritmos de encriptación para los tickets de Kerberos. Dado que en las versiones más recientes de Kerberos la lista de algoritmos ha sido marcada como insegura, es necesario incluir el parámetro allow_weak_crypto para que Kerberos la admita. • Reinos de Kerberos: En este bloque se configura donde está el centro de distribución de claves que el reino de Kerberos WSO2.ORG va a utilizar. En este caso, contiene el alias de la dirección IP del IS. 4.7.1.3. Archivo de configuración de cliente – Jaas.conf Este archivo configura el servicio de autenticación y autorización de Java (Java Authentication and Authorization Service - JAAS) [18]. Este servicio es la implementación del módulo de autenticación de Linux, pero en Java. Este archivo es utilizado por el cliente para la configuración de algunos parámetros del módulo de Kerberos. Para configurar el servicio de autenticación de Java, es necesario crear un archivo llamado jaas.conf con el siguiente contenido: Client { com.sun.security.auth.module.Krb5LoginModule required useTicketCache=false; }; Esta configuración se añade para que el cliente no utilice ninguna caché para almacenar los tickets de Kerberos, de tal forma de que en cada ejecución del caso práctico se realice la autenticación del usuario que accede al servicio mediante Kerberos. La ruta en la que debe colocarse este archivo es: clienteKerberos/org.wso2.identity.esb.kerberos/repo/conf/Jaas.conf 68 4.7.1.4. Archivo de configuración de cliente – policy.xml Este archivo contiene las políticas que configuran el cliente que accede al servicio de eco. Si se observa el archivo se puede ver que este contiene los esquemas de configuración que utiliza el servicio de eco sobre políticas de seguridad: Figura 4-40 – Configuración de políticas de seguridad para el cliente del servicio eco Y la configuración de Kerberos: Figura 4-41- Configuración de Kerberos para el cliente del servicio de eco Donde se incluye un enlace al archivo de configuración de Kerberos, el principal al que quiere acceder el usuario junto a los datos de inicio de sesión de usuario. 69 Este archivo es necesario modificarlo para incluir los datos de inicio de sesión y el principal que se utilizan en el caso práctico. 4.7.1.5. Código Java del cliente Este es el archivo principal que contiene el código Java que gestiona el acceso al servicio de eco. Este hace uso de las librerías de WSO2 de forma que la autenticación de Kerberos es invisible para el desarrollador. Este archivo de código se puede dividir en 2 partes: • Configuración del contexto, donde se carga el archivo de configuración de WSO2 que define que versiones de protocolos se van a utilizar para la comuniación con el servicio de eco y la carga de las políticas del cliente, las cuales se enviarán junto con el contenido de la petición al servicio. Figura 4-42 – Configuración del contexto del cliente del servicio de eco • El bucle de código principal, donde se utiliza el contexto que se ha cargado anteriormente y se le pregunta al usuario por dos parámetros: o La URL donde el servicio de eco ha sido desplegado o El mensaje que se desea enviar al servicio de eco 70 Figura 4-43 Bucle principal de código del cliente del servicio de eco Como se puede ver, en ningún momento se configuran los detalles de la autenticación del cliente contra Kerberos, eso es tarea de las librerías de la aplicación, las cuales al leer el archivo de políticas del cliente comprobarán que se autentica mediante Kerberos. 4.7.2. Ejecución Una vez configurado el archivo de políticas con la información requirida y teniendo en cuenta de que el IS y el ESB necesitan estar ejecutándose, se puede ejecutar el cliente. Para ello, hay que navegar hacia el directorio donde se haya descomprimido el cliente (en el caso que se muestra a continuación ha sido sobre el directorio raiz): cd /home/$(whoami)/clienteKerberos/org.wso2.identity.esb.kerberos/ Y ejecutar el siguiente comando: ant run La compilación y ejecución del cliente está automatizada, por lo que: 71 Figura 4-44 Traza de ejecución del cliente Como se aprecia en la captura de pantalla, durante la ejecución se le solicita al usuario la URL del servicio de eco, la cual puede ser obtenida observando el panel de administración del servicio en el ESB, y el texto que se quiere enviar al servicio de eco. Si durante la ejecución de este caso práctico alguno de los parámetros no ha sido configurado correctamente, como por ejemplo, diferencias en el identificador del servicio de eco en los distintos archivos, se obtendrá una traza de ejecución del cliente similar a: [java] GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7) - Server not found in Kerberos database) [java] at java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:771) [java] at java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:265) [java] at java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:196) [java] at org.apache.ws.security.message.WSSecKerberosToken$1.run(WSSecKerberosToken.java:131) [java] at org.apache.ws.security.message.WSSecKerberosToken$1.run(WSSecKerberosToken.java:119) [java] at java.base/java.security.AccessController.doPrivileged(Native Method) [java] at java.base/javax.security.auth.Subject.doAs(Subject.java:361) [java] at org.apache.ws.security.message.WSSecKerberosToken.getServiceTicketData(WSSecKerberosToken.java:119) [java] at org.apache.ws.security.message.WSSecKerberosToken.prepare(WSSecKerberosToken.java:193) [java] at org.apache.ws.security.message.WSSecKerberosToken.build(WSSecKerberosToken.java:91) Una vez el caso práctico ha sido ejecutado, se pueden ver estadísticos básicos del servicio accediendo al pandel de adminstración del servicio de eco en el ESB: 72 Figura 4-45 Métricas del tiempo de respuesta del servicio de eco En la imagen se aprecia como se ha hecho uso del servicio varias veces, los tiempos de respuesta máximos y mínimos y una gráfica de los tiempos de respuesta. Se puede ver como tras cierto tiempo de uso del servicio el tiempo medio de respuesta está sobre los 32 milisegundos. 4.8. Análisis trazas de ejecución del cliente Es posible obtener más trazas de ejecución del cliente en el lado del IS y del ESB, donde se puede obtener información sobre los tickets de Kerberos solicitados y las trazas de la conexión con el servidor de eco. Por defecto en los servidores IS y ESB el nivel de verbosidad de las trazas del sistema está configurado a INFO, el cual no muestra información sobre los tickets de Kerberos utilizados. Para cambiar el nivel de verbosidad, hay que: • Conectarse a la consola de administración del sistema y acceder a la sección de logging dentro de la sección de configuración: 73 Figura 4-46 – Acceso a la configuración de trazas de sistema del IS • Dentro de esta sección, se cambia el parámetro de configuración de INFO a DEBUG: Figura 4-47 – Cambio de configuración de trazas de sistema en el IS Una vez hecho, se utiliza la opción update para guardar este cambio. Para observar los tickets de Kerberos en las trazas del sistema del IS o el ESB, hay que acceder a la sección de trazas del sistema, dentro de la sección de monitorización: 74 Figura 4-48 – Acceso a la sección de monitorización del IS Dentro de esta sección es posible descargar el archivo de trazas llamado wso2carbon.log, el cual contiene las trazas de ejecución del cliente. Si una vez descargado este archivo se examina el contenido del mismo, se encuentra las trazas del servidor de autenticación (es una parte del KDC de Kerberos): Petición de autenticación del cliente que accede al servicio de eco. Aquí se incluye la información que ha sido configurada en los archivos de configuración de Kerberos, como algoritmos, versión de protocolo de Kerberos… Si se sigue examinando el archivo se puede ver las trazas de la búsqueda del IS en la base de datos LDAP de información del usuario que accede al servicio de eco: 75 Figura 4-49 – Búsqueda de usuario en base de datos LDAP Así como la petición de un TGS (ticket de servicio) para el servicio de eco: Figura 4-50 – Petición de ticket de servicio para el servicio de eco Y su respuesta: Figura 4-51 – Respuesta de creación de TGS para el servicio de eco Si se realiza la misma operación en el ESB, es posible encontrar las trazas de ejecución del cliente cuando 82 83 6 BIBLIOGRAFÍA • [1] WSO2, Information of the Company. Disponible en: http://wso2.com/about/. Último acceso el 6 de Septiembre de 2018 • [2] WSO2, Platform. Disponible en: http://wso2.com/platform. Último acceso el 6 de Septiembre de 2018 • [3] WSO2 API management. Disponible en: https://wso2.com/api-management/. Último acceso el 6 de Septiembre de 2018 • [4] WSO2 Identity Server. Disponible en: https://docs.wso2.com/display/IS530/WSO2+Identity+Server+Documentation. Último acceso el 6 de Septiembre de 2018 • [5] WSO2 Identity and access management. Disponible en: https://wso2.com/identity-and-access- management/. Último acceso el 6 de Septiembre de 2018 • [6] WSO2 IOT. Disponible en: https://wso2.com/iot . Último acceso el 8 de Septiembre de 2018 • [7] Middleware Architecture with Patterns and Frameworks (Capítulo 2). Disponible en: https://paginas.fe.up.pt/~apm/TDIN/docs/architecture_patterns_book.pdf. Último acceso el 8 de Septiembre de 2018 • [8] WSO2 Carbon. Disponible en: https://wso2.com/products/carbon/ . Último acceso el 8 de Septiembre de 2018 • [9] Service-Oriented architecture. Disponible en: https://en.wikipedia.org/wiki/Serviceoriented_architecture. Último acceso el 8 de Septiembre de 2018 • [10] SOA reference architecture. Disponible en: http://www.opengroup.org/soa/source-book/soa_refarch/. Último acceso el 8 de Septiembre de 2018 • [11] Qué se entiende por SOA y cuales son sus beneficios. Disponible en: http://www.i2btech.com/blog- i2b/tech-deployment/que-se-entiende-por-soa-y-cuales-son-sus-beneficios/. Último acceso el 12 de Septiembre de 2018 • [12] Service-Oriented Architecture definition. Disponible en: https://www.servicearchitecture.com/articles/web-services/service-oriented_architecture_soa_definition.html. Último acceso el 12 de Septiembre de 2018 • [13] WSO2 Enterprise Service Bus documentation. Disponible en: https://docs.wso2.com/display/ESB500/WSO2+Enterprise+Service+Bus+Documentation. Último acceso el 12 de Septiembre de 2018 • [14] The Kerberos Network Authentication Service. Disponible en: https://tools.ietf.org/html/rfc1510. Último acceso el 12 de Septiembre de 2018 • [15] How the Kerberos V5 Authentication Protocol Works. Disponible en: https://docs.microsoft.com/enus/previous-versions/windows/it-pro/windows-server-2003/cc772815(v=ws.10). Último acceso el 12 de Septiembre de 2018 • [16] Kerberos Authentication using WSO2 products. Disponible en: https://wso2.com/library/articles/2012/07/kerberos-authentication-using-wso2-products/. Último acceso el 22 de Septiembre de 2018 • [17] Project Athena. Disponibel en: https://en.wikipedia.org/wiki/Project_Athena. Último acceso el 22 de Septiembre de 2018 84 • [18] Java Authentication and Authorization Service. Disponible en: https://docs.oracle.com/javase/8/docs/technotes/guides/security/jaas/JAASRefGuide.html. Último acceso el 22 de Septiembre de 2018 • [19] Distributed Systems: Concepts and Design, 4/e - Couloris. Último acceso el 24 de Septiembre de 2018 • [20] Tech Journey, Secure WSO2 ESB REST APIs using Kerberos. Disponible en: http://hasanthipurnima.blogspot.com.es/2016/07/secure-wso2-esb-rest-apis-using-kerberos.html. Último acceso el 24 de Septiembre de 2018 85 86 7 GLOSARIO SOAP: Simple Object Access Protocol SOA: Service Oriented Architecture HTML: HyperText Markup Language HTTP: HyperText Transfer Protocol XML: Extensible Markup Language REST: Representational Transfer Protocol KDC: Key Distribution Center TGT: Ticket-Granting Ticket TGS: Ticket Granting Server AS: Authentication Server IS: Identity Server ESB: Enterprise Bus Service PDP: Punto de decisión de políticas PIP: Punto de información de políticas API: Application Programming Interface URL: Uniform Resource Locator SMTP: Simple Mail Transfer Protocol WSDL: Web Services Description Language Apache: Web Server Tomcat: Web Server focused on Java Applications Java: Programming language POP: Post Office Protocol IMAP: Internet Message Access Protocol 87 88 Anexo A: Código del cliente del servicio eco Este anexo incluye el código del cliente que accede al servicio de eco: /** * El programa cliente que accede al servicio de eco bajo la aunteticacion de Kerberos. */ public class clienteKerberos { private static ConfigurationContext confContext = null; private static Policy servicePolicy = null; public static final String ANSI_YELLOW = "\u001B[33m"; public static final String ANSI_RESET = "\u001B[0m"; public static void main(String[] args) throws Exception { // Crea el contexto de configuracion utilizando el archivo client.axis2.xml confContext = ConfigurationContextFactory.createConfigurationContextFromFileSystem("repo", "repo/conf/client.axis2.xml"); servicePolicy = loadServicePolicy("repo/conf/policy.xml"); run(); System.exit(0); } /** * Carga las politicas del cliente. * @param xmlPath ruta hacia el archivo de politicas. * @return un objeto de politicas * @throws Exception si el objeto que contiene las politicas no puede ser creado. */ 89 private static Policy loadServicePolicy(String xmlPath) throws Exception { StAXOMBuilder builder; Policy policy; builder = new StAXOMBuilder(xmlPath); policy = PolicyEngine.getPolicy(builder.getDocumentElement()); return policy; } /** * Construye la carga que se enviara en la peticion del cliente al ESB. * @param value la cadena que se enviara al servicio de eco. * @return un objeto que contiene la carga que se envia al servicio de eco. */ private static OMElement getPayload(String value) { OMFactory factory = OMAbstractFactory.getOMFactory(); OMNamespace ns = factory.createOMNamespace("http://echo.services.core.carbon.wso2.org", "ns1"); OMElement elem = factory.createOMElement("echoString", ns); OMElement childElem = factory.createOMElement("in", null); childElem.setText(value); elem.addChild(childElem); return elem; } /** * Este metodo invoca al servicio. */ public static void run() { ServiceClient client = null; String s = null; try { // Obten la URL del servicio de eco por parametros Scanner reader = new Scanner(System.in); System.out.println("Introduce la URL del servicio de eco: "); System.out.println("(Ejemplo: http://wso2esb:8280/services/echo)"); String URL_SERVICIO_ECO = reader.nextLine(); 90 client = new ServiceClient(confContext, null); Options options = new Options(); // Configura el servicio al que se quiere acceder options.setAction("urn:echoString"); // Configura el endpoint options.setTo(new EndpointReference(URL_SERVICIO_ECO)); // Configura las politicas del servicio options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, servicePolicy); client.setOptions(options); // Configura el modulo Rampart de Apache client.engageModule("rampart"); // Obten la cadena que se le va a enviar al servicio de eco por parametros System.out.println("Introduce el texto a enviar al servicio de eco: "); String cadena_servicio_eco = reader.nextLine(); reader.close(); OMElement response = client.sendReceive(getPayload(cadena_servicio_eco)); System.out.println(ANSI_YELLOW + "### EJECUCION DEL CLIENTE WSO2 ###" + ANSI_RESET); System.out.println(); System.out.println(ANSI_YELLOW + "Enviando al sericio de eco la cadena:" + ANSI_RESET + "\n" + ANSI_YELLOW + cadena_servicio_eco + ANSI_RESET); System.out.println(); System.out.println(ANSI_YELLOW + "Respuesta del servidor WSO2ESB:" + ANSI_RESET + "\n" + ANSI_YELLOW + response + ANSI_RESET); } catch (AxisFault axisFault) { axisFault.printStackTrace(); System.err.println("No he podido configurar correctamente el cliente que accede al servicio"); } finally { if (client != null) { try { client.cleanup(); } catch (AxisFault axisFault) { System.err.println("Error limpiando el cliente que accede al servicio"); 91 } } } } }