i Equation Chapter 1 Section 1 Proyecto Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Personalización del servicio de identidad de WSO2 al dominio sanitario Autor: Enrique Gil Reina Tutor: Isabel Román Martínez Dep. De Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla
154
Embed
Proyecto Fin de Gradobibing.us.es/proyectos/abreproy/90865/descargar... · Proyecto Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Personalización del
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
i
Equation Chapter 1 Section 1
Proyecto Fin de Grado
Grado en Ingeniería de las Tecnologías de
Telecomunicación
Personalización del servicio de identidad de WSO2
al dominio sanitario
Autor: Enrique Gil Reina
Tutor: Isabel Román Martínez
Dep. De Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
ii
iii
Proyecto Fin de Grado
Grado en Ingeniería de las Tecnologías de Telecomunicación
Personalización del servicio de identidad de WSO2
al dominio sanitario
Autor:
Enrique Gil Reina
Tutor:
Isabel Román Martínez
Profesora colaboradora
Dep. De Ingeniería Telemática
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2016
iv
v
Proyecto Fin de Grado: Personalización del servicio de identidad de WSO2 al dominio sanitario
Autor: Enrique Gil Reina
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, 2016
El Secretario del Tribunal
vi
vii
A mi familia, a mis amigos y a mi pareja
Por su amor, cariño y comprensión
y por estar ahí… como siempre
viii
ix
Agradecimientos
Este no es el típico párrafo de agradecimiento en el que hablo de mis seres queridos y allegados
agradeciéndoles todo lo que han hecho por mí y lo que, por seguro, seguirán haciendo durante el tiempo de
vida que me queda. Ellos bien saben que les debo todo lo que tengo y todo lo que soy, no hay agradecimiento
alguno que pueda compensar su dedicación y empeño en convertirme en una persona de provecho, con
principios y útil para la sociedad.
En lugar de esto, permítanme que comparta un par de citas que realmente determinan mi forma de pensar y de
ser y que, sin lugar a duda, marcan todas y cada una de las acciones que llevo a cabo en la vida de una u otra
manera. Gracias.
El que muere no puede llevarse nada de lo que consiguió, pero se lleva, con toda seguridad, todo lo que dio.
Padre Mamerto Menapace
No hay finales aparte de la muerte, sólo descansos para recobrar el aliento y empezar de nuevo. Siempre
empezar de nuevo… Por eso el mundo está cada vez más abarrotado, ¿entiendes? De modo que recuerda
esto: no hay finales, sólo principios. Ahí tienes. Así de sencillo. Y también elegante, ¿verdad?
Ed Greenwwod
Elminster, La forja de un mago
x
xi
Índice
Agradecimientos ix
Índice xi
Índice de Tablas, ejemplos e ilustraciones xiii
Índice de Imágenes y Capturas xv
Lista de abreviaturas y símbolos xix
Introducción 1 1 Motivación 1 2 Objetivos 3 3 Planificación y dedicación 3 4 Organización del documento 5
Estado de la técnica 7 1 Contexto 7 2 Conceptos previos 8
3 Introducción a los componentes de WSO2 19 3.1 Introducción al Identity Server 23 3.2 Introducción al Application Server 27
Desarrollo del proyecto 29 1 Instalación y análisis de las funcionalidades del Identity Server 31 2 Creación de un dialecto siguiendo la norma XSPA XACML de OASIS 43 3 Creación y evaluación de políticas de control de acceso 57
3.1 Uso de la herramienta PAP del IS para la creación y evaluación de políticas 57 3.2 Uso de SoapUI para la evaluación de políticas 65
4 Instalación y análisis de las funcionalidades básicas del Application Server 72 5 Creación del escenario de prueba 76
5.1 Introducción 76 5.2 Esquema del escenario de prueba 77 5.3 Configuración del escenario de prueba 78 5.4 Test de funcionamiento del escenario de prueba 81
Bibliografía 91 1 Recursos/Ensayos/papers del ámbito de la salud 91 2 XACML 91 3 SAML 91 4 SOAP 91
xii
5 LDAP 91 6 OASIS 92 7 WSO2 92 4 WSO2 Identity Server 92 5 WSO2 Aplication Server 92 6 Apache Directory Server 92 7 SoapUI 93 8 Escenario de prueba 93 9 Investigaciones relacionadas con WSO2 93 10 Otros 93
Anexos 95 ANEXO A. SERVIDOR DE IDENTIDAD DE WSO2 (VERSIÓN 5.1.0) 95
Archivos de configuración modificados/creados 97 ANEXO B. SERVIDOR DE APLICACIONES DE WSO2 (VERSIÓN 5.3.0) 113
Archivos de configuración modificados/creados 116 Archivos y recursos de la Aplicación Web Genérica 118 Archivos y recursos de la Aplicación Web del escenario de prueba 123
xiii
ÍNDICE DE TABLAS, EJEMPLOS E
ILUSTRACIONES
Tabla 1. Envoltorio de un mensaje SOAP 11
Tabla 2. Cabecera de un mensaje SOAP 11
Tabla 3. Cuerpo de un mensaje SOAP 12
Tabla 4. Principales atributos de nuestros archivos LDIF 49
Tabla 5. Características principales de nuestros archivos LDIF 49
Ejemplo 1. Mensaje SOAP embebido en una petición HTTP 12
Ejemplo 2. Mensaje SOAP embebido en una respuesta HTTP 12
Ilustración 1. Fases del proyecto 4
xiv
xv
ÍNDICE DE IMÁGENES Y CAPTURAS
Imagen 1. Esquema general Sistema de Control de Acceso 2
Imagen 2. Esquema simplificado de un Sistema de control de Acceso 8
Imagen 3. Esquema de uso de SAML 9
Imagen 4. Intercambio de mensajes SOAP 10
Imagen 5. Esquema de funcionamiento de LDAP 13
Imagen 6. LDAP DIT Information/Data Model (I) 14
Imagen 7. LDAP DIT Information/Data Model (II) 15
Imagen 8. Representación de esquemas LDAP compuestos de objectClasses y atributos 16
Imagen 9. Diagrama explicativo del uso de RDNs y DNs (I) 17
Imagen 10. Diagrama explicativo del uso de RDNs y DNs (II) 17
Imagen 11. Ámbitos tecnológicos WSO2 19
Imagen 12. Esquema genérico de la plataforma Carbon WSO2 20
Imagen 13. Visión general de la suite de productos de WSO2 21
Imagen 14. Comparativa de plataformas SOA 22
Imagen 15. Tabla de características del IS 23
Imagen 16. Arquitectura genérica del IS 24
Imagen 17. Funcionalidades del IS 26
Imagen 18. Esquema de funcionamiento del AS (I) 27
Imagen 19. Esquema de funcionamiento del AS (II) 27
Imagen 20. Esquema de funcionamiento del repositorio de WSO2 72
Imagen 21. Motor de evaluación de políticas XACML 76
Imagen 22. Esquema funcional del escenario de prueba realizado 77
Imagen 23. Esquema conceptual del escenario de prueba montado 77
Imagen 24. Relación del sistema de control de acceso con los componentes WSO2 IS y AS. 78
Imagen 25. Estructura de directorios de la aplicación web creada 80
Imagen 26. Mapa-mundi de WSO2 88
Imagen 27. Campos tecnológicos a los que se dedica WSO2 89
Imagen 28. Diagrama de uso de los productos de WSO2 89
Captura 1. Pantalla de inicio de sesión en la consola de gestión del IS 31
Captura 2. Menú principal del IS 32
Captura 3. Pantalla de Administración de Políticas del IS 33
Captura 4. Pantalla de adición de nuevas políticas 33
Captura 5. Pantalla de creación de políticas XACML 34
Captura 6. Pantalla de prueba de políticas 34
Captura 7. Pantalla de evalución de políticas (código de la petición XACML) 35
xvi
Captura 8. Pantalla de publicación de políticas 35
Captura 9. Pantalla de visualización de políticas 36
Captura 10. Pantalla de gestión de usuarios y roles 36
Captura 11. Pantalla de gestión de usuarios 37
Captura 12. Pantalla de asignación de roles a un usuario 37
Captura 13. Pantalla de configuración de los atributos de un usuario 38
Captura 14. Pantalla de gestión de roles 38
Captura 15. Pantalla de gestión de los “almacenamientos” de usuarios 39
Captura 16. Pantalla de creación de un nuevo “almacenamiento” de usuarios 39
Captura 17. Pantalla de gestión de dialectos y atributos (claims) 40
Captura 18. Pantalla de creación de nuevo dialecto 40
Captura 19. Pantalla de creación de un nuevo atributo (en un dialecto) 41
Captura 20. Pantalla con el listado de dialectos existentes en el IS 41
Captura 21. Listado de claims (atributos) de un dialecto 42
Captura 22. Pantalla de gestión de atributos (claims) 42
Captura 23. Parte del dialecto que utiliza por defecto el IS editado con nuestros atributos 43
Captura 24. Dialectos existentes por defecto en el IS (archivo de configuración claim-config.xml) 44
Captura 25. Definición de un atributo cualquiera (archivo de configuración claim-config.xml) 44
Captura 26. Listado de atributos estándar de la norma OASIS utilizada como referencia 46
Captura 27. Resultado final del dialecto por defecto tras modificación (completo) 47
Captura 28. Archivos LDIF por defecto del IS 48
Captura 29. Archivo de configuración LDIF necesario para utilizar los nuevos atributos del dialecto 50
Captura 30. Archivo de configuración LDIF para los atributos OASIS 51
Captura 31. Pantalla principal de Apache Directory Studio (I) 52
Captura 32. Pantalla de configuración de la conexión al LDAP 52
Captura 33. Pantalla de configuración de la conexión LDAP (I) 53
Captura 34. Pantallas de configuración de la conexión LDAP (II) 53
Captura 35. Pasos para importar un archivo LDIF 54
Captura 36. Pantalla de importación de archivos LDIF 54
Captura 37. Cambio introducido en el archivo embedded-ldap.xml 55
Captura 38. Cambio introducido en el archivo user-mgt.xml 55
Captura 39. Pantalla principal de Apache Directory Studio (II) 56
Captura 40. Pantalla de administración de políticas 57
Captura 41. Ventana de edición de políticas 57
Captura 42. Ejemplo de atributo insertado en el dialecto por defecto del IS 58
Captura 43. Parte del archivo LDIF creado para mapear los atributos insertados en el dialecto 58
Captura 44. Valor dado a los atributos de los usuarios creados en el IS 58
Captura 45. Prueba o testeo de la política “MiPrimeraPolitica” 59
Captura 46. Resultado de la evaluación de la política (I) 59
Captura 47. Resultado de la evaluación de la política (II) 59
xvii
Captura 48. Petición XACML para la política “MiPrimeraPolitica” (I) 60
Captura 49. Resultado de la petición XACML realizada sobre la política “MiPrimeraPolitica” (I) 60
Captura 50. Petición XACML para la política “MiPrimeraPolitica” (II) 61
Captura 51. Resultado de la petición XACML realizada sobre la política “MiPrimeraPolitica” (II) 61
Captura 52. Código XACML de la política “MiSegundaPolitica” 62
Captura 53. Pantalla de evaluación de la política “MiSegundaPolítica” 62
Captura 54. Código necesario para introducir el atributo “purposeOsUse” en el dialecto por defecto 63
Captura 55. Petición XACML para la política “MiSegundaPolitica” (I) 63
Captura 56. Resultado de la petición XACML realizada sobre la política “MiSegundaPolitica” (I) 63
Captura 57. Petición XACML para la política “MiSegundaPolitica” (II) 64
Captura 58. Resultado de la petición XACML realizada sobre la política “MiSegundaPolitica” (II) 64
Captura 59. Petición XACML para la política “MiSegundaPolitica” (III) 65
Captura 60. Resultado de la petición XACML realizada sobre la política “MiSegundaPolitica” (III) 65
Captura 61. Ejemplo de archivo “wsdl” del IS mostrado en un navegador web 66
Captura 62. Listado de servicios web ofrecidos por el IS 67
Captura 63. Ventana de configuración de un nuevo servicio en SoapUI 68
Captura 64. Configuración de la autencicación necesaria para el uso de servicios en SoapUI 68
Captura 65. Ejemplo de uso de un determinado servicio en SoapUI (I) 69
Captura 66. Ejemplo de uso de un determinado servicio en SoapUI (II) 69
Captura 67. Uso del servicio “EntitlementService” para probar la política “MiSegundaPolitica” (I) 70
Captura 68. Uso del servicio “EntitlementService” para probar la política “MiSegundaPolitica” (II) 70
Captura 69. Uso del servicio “EntitlementService” para probar la política “MiSegundaPolitica” (III) 71
Captura 70. Uso del servicio “EntitlementService” para probar la política “MiSegundaPolitica” (IV) 71
Captura 71. Pantalla de instalación de funcionalidades y características adicionales (módulos) 72
Captura 72. Valor del atributo “offset” del archivo “Carbon.xml” del AS 73
Captura 73. Pantalla de inicio de sesión del WSO2 Application Server 73
Captura 74. Pantalla de incio del AS 74
Captura 75. Pantalla con el listado de aplicaciones corriendo actualmente en el AS 74
Captura 76. Información y estadísticas de una determinada aplicación web del AS 75
Captura 77. Aplicación Web de prueba desplegada en el AS 75
Captura 78. Código XACML de la política “Entitlement_Filter_Sample_Policy” 79
Captura 79. Listado de aplicaciones web desplegadas en el AS (después de incluir las dos nuevas) 80
Captura 80. Listado de las aplicaciones web desplegadas en el AS 81
Captura 81. Página de inicio de la aplicación web (index.jsp) creada para el escenario de prueba (I) 81
Captura 82. Página de inicio de la aplicación web (index.jsp) creada para el escenario de prueba (II) 82
Captura 83. Opción de añadir nuevo usuario en el AS 82
Captura 84. Apartado de usuarios y roles dentro del AS 82
Captura 85. Pantalla emergente de identificación de usuario de la aplicación web (index.jsp) 83
Captura 86. Pantalla de acceso permitido al recurso protegido (protected.jsp) 83
Captura 87. Pantalla de acceso prohibido al recurso protegido (error.jsp) 84
xviii
Captura 88. Pantalla de error de autenticación obligatoria 84
Captura 89. Diagrama de secuencias del funcionamiento de la aplicación web 85
xix
LISTA DE ABREVIATURAS Y SÍMBOLOS
SOA Service-Oriented Architecture
API Application programming interface
SSO Single Sign-On
IS Identity Server
AS Aplication Server
XACML Extensible Access Control Markup Language
XSPA Cross-Enterprise Security and Privacy Authorization
SAML Security Assertion Markup Language
PAP Policy Administration Point
PEP Policy Enforcement Point
PDP Policy Decision Point
PIP Policy Information Point
PRP Policy Retrieval Point
LDAP Lightweight Directory Access Protocol
LDIF LDAP Data Interchange Format
SOAP Simple Object Access Protocol
SCIM System for Cross-domain Identity Management
RPC Remote Procedure Call
JDBC Java Database Connectivity
OASIS Organization for the Advancement of Structured Information Standards
xx
1
INTRODUCCIÓN
En el apartado de introducción se van a definir los motivos que han propiciado el desarrollo y ejecución de este
proyecto, así como los objetivos que se marcaron inicialmente, su alcance, la metodología seguida para
cumplirlos y, por último, la organización o estructura que se le ha dado a toda la información recogida en esta
memoria.
1 Motivación
Una de las líneas de investigación del Grupo de Ingeniería Biomédica de la Universidad de Sevilla se centra en
la integración de sistemas sanitarios y el desarrollo de componentes en sistemas distribuidos. Una de las
mayores dificultades encontradas por el Grupo es la implementación de prototipos funcionales, dado que es
difícil desarrollar un sistema distribuido completo, con las prestaciones de alto nivel deseadas, desde cero.
Existe una gran variedad de soluciones que se podrían utilizar para resolver esta cuestión, pero bien algunas de
ellas son de pago o bien otras no presentan todas las prestaciones deseadas. WSO2 ([21] , [23] , [45] , [46] ,
[47] , [48] y [49] ), una empresa fundada en 2005, ofrece un completo set de herramientas de código 100%
abierto (Open Source) que permiten a particulares y empresas construir una arquitectura orientada a servicios
(SOA) completa. De este modo, adaptar WSO2 al dominio sanitario permitirá tener una plataforma SOA
funcional y completa que facilite la implementación de prototipos para validar los resultados de investigación
del Grupo.
La mayor parte de las empresas necesitan mecanismos para intercambiar políticas de seguridad y privacidad,
evaluar directivas de autorización y determinar autorizaciones de forma automática y conjunta.
Concretamente, en el caso de las entidades del ámbito sanitario, esta necesidad llega a resultar crítica, ya que
se maneja gran cantidad de información sensible (privada) de multitud de usuarios. Uno de los estándares que
nos permite gestionar los mecanismos de control necesarios para asegurar la integridad y confidencialidad
de los datos manejados es XACML (eXtensible Access Control Markup Language) ([6] y [7] ).
Mediante la utilización de este lenguaje, se puede administrar fácilmente el uso que hace el personal
sanitario de la información confidencial de los distintos usuarios en función de una serie de características
predefinidas que lo identifican perfectamente dentro del entorno en el que se ubica.
Adicionalmente, el perfil XSPA de OASIS (Cross-Enterprise Security and Privacy Authorization Profile of
XACML v2.0 for Healthcare Version 1.0) ([19] y [20] ) especifica en uno de sus estándares el uso de
XACML 2.0 para promover la interoperatividad de políticas de control de acceso en el ámbito de la salud,
proporcionando reglas semánticas comunes y definiendo un vocabulario estándar para poder trabajar con
políticas (evaluación, aplicación y ejecución de políticas). Dicho de otra forma, XSPA describe un amplio
conjunto de mecanismos para autenticar, administrar e imponer políticas de autorización que controlan el
acceso a información sensible o protegida (almacenada dentro o fuera de las fronteras de las empresas)
dentro del ámbito médico o de la salud. Además, este perfil también puede ser utilizado en conjunto con
otros estándares como WS-Trust o SAML (Security Assertion Markup Language) ([8] ), lo cual le aporta
un mayor nivel de utilidad y versatilidad.
En nuestro caso, se pretende realizar la adaptación del componente WSO2 Identity Server (el cual ofrece
funcionalidades de control de acceso a recursos mediante el uso de XACML) al ámbito sanitario tomando
como referencia el estándar OASIS mencionado anteriormente (XSPA).
2
Para terminar, se muestra el esquema genérico del sistema de control de acceso que deseamos llevar a cabo en
este proyecto ([20] ):
Imagen 1. Esquema general Sistema de Control de Acceso
3
2 Objetivos
A continuación se exponen los objetivos que han marcado la ruta a seguir en este proyecto. Cabe destacar que
la planificación y metodología seguidas para cumplir dichos objetivos serán desarrolladas brevemente en el
siguiente subapartado y serán detalladas a fondo en el apartado Desarrollo del proyecto.
Los principales objetivos que se fijaron para la realización del proyecto son los siguientes:
La implementación de un sistema de control de acceso a recursos basado en el uso del componente
WSO2 Identity Server (de ahora en adelante, IS), adaptado al estándar médico XSPA de OASIS.
El montaje de un escenario de prueba con el que probar el funcionamiento y utilidad del sistema
elaborado con la ayuda de otro componente WSO2, el Application Server (de ahora en adelante, AS).
3 Planificación y dedicación
Tal y como se indicó en el subapartado anterior, ahora procedemos con la metodología o planificación que se
ha seguido para llevar a cabo los objetivos. Para ello, se ha dividido el procedimiento seguido en el proyecto
en varias fases, las cuales se detallan a acontinuación:
Recopilación, búsqueda y análisis de la información: la mayor parte de la información y recursos
que se han utilizado en este proyecto se han obtenido de la documentación oficial proporcionada por
WSO2 en su página web oficial, aunque también se han utilizado fuentes de información ajenas a la
oficial, en su totalidad recursos web (papers, estudios, proyectos, investigaciones, tutoriales, etc.). Otra
gran fuente de información y ayuda ha sido el foro oficial de WSO2 en StackOverFlow ([22] ), donde
usuarios expertos y profesionales de WSO2 proporcionan ayuda fiable acerca de cuestiones
relacionadas con los productos que ofrece WSO2.
Esta fase ocupó una buena parte del tiempo dedicado al desarrollo del proyecto, ya que el IS es una
aplicación que ofrece una gran cantidad de herramientas de gestión y funcionalidades (para usuarios,
roles, políticas, servicios, etc.), siendo complicado llegar a controlar y entender todas las posibilidades
que ofrece.
En este sentido hay que indicar que, aunque se ha conseguido recabar toda la información necesaria
para poder llevar a cabo el proyecto, en determinados casos ha resultado bastante costoso encontrar la
información adecuada para poder seguir avanzando (y en circunstancias eventuales no se ha llegado a
encontrar siquiera dicha información).
Instalación, configuración y puesta en funcionamiento del IS: con respecto a la instalación del
componente Identity Server, poco hay que comentar. Simplemente hay que acceder a la página web
de WSO2, buscar el apartado correspondiente al IS, descargar el archivo comprimido, descomprimirlo
en nuestro equipo y ejecutar el archivo wso2server.bat (ejecutable que arranca el IS
automáticamente). Al ejecutar el archivo indicado, por defecto, se arranca la interfaz web del IS en la
dirección http://localhost:9443/carbon/ de nuestro equipo, por lo que sólo deberíamos introducir dicha
URL en nuestro navegador web, iniciar sesión y ya podríamos empezar a interaccionar con las
funcionalidades del IS.
A la vista de lo anteriormente comentado, indicar que no se han encontrado grandes dificultades para
llevar a cabo esta tarea.
Creación de un dialecto propio y adaptado al ámbito de la salud: este es quizás el principal pilar
sobre el que se sustentaba el desarrollo del trabajo y el motivo fundamental por el que toda esta
investigación tiene aplicación directa sobre un entorno empresarial real. El objetivo es claro, crear un
dialecto1 único y adaptado al estándar XSPA de OASIS (aunque el procedimiento sería extensible a
otros del mismo modo).
1 Un “Dialecto” o “Claim Dialect” no es más que un conjunto de atributos o “claims” que definen, caracterizan e identifican a un usuario dentro de un entorno concreto. De esta forma, dependiendo del ámbito en el que nos encontremos, se pueden usar distintos tipos de dialectos según nos convenga.
Con esto, se ha conseguido que los atributos que definen por defecto a las entidades dadas de alta en el
IS sigan las directrices que establece la norma o estándar XSPA según nos convenga, consiguiendo
que pueda ser utilizado en cualquier ámbito médico de forma genérica.
Sin embargo, en este punto hay que hacer una pequeña puntualización, ya que no se ha conseguido
crear un nuevo dialecto adaptado a nuestros intereses que pueda utilizar el IS (por motivos que se
explicarán en el apartado Desarrollo del proyecto). Lo que se ha conseguido es modificar el dialecto
que utiliza por defecto el IS para hacer que los atributos que definen a las entidades del sistema sean
los que dictamina la norma OASIS tomada como referencia.
Creación de un set de políticas XACML: con esta tarea lo que se buscaba es, una vez creado y
establecido un dialecto que sigue las directrices de la norma o estándar que se ha tomado como
referencia, elaborar una serie de restricciones (políticas de acceso) que controlan el acceso a
determinada información sensible en función del valor que toman los atributos (del dialecto creado en
la tarea anterior) que definen las entidades en el IS.
De esta forma, estaríamos probando el correcto funcionamiento del dialecto creado y haciendo
pruebas sencillas de posibles reglas o políticas que se pueden establecer para controlar el acceso de
usuarios en el ámbito que nos concierne, el de la salud.
Por último, mencionar que en esta fase no se han encontrado problemas a la hora de crear y probar las
políticas correspondientes.
Desarrollo del escenario de prueba: por último, pero no por ello menos importante, se ha buscado
realizar un escenario sencillo en el que se aprecie el correcto funcionamiento de todas las
modificaciones y configuraciones realizadas en el IS. Con ello, se muestra una idea de la aplicación
que tendría el proyecto en un entorno empresarial real (enfocado al ámbito de la salud, aunque
también trasladable al ámbito que se quisiera).
Con respecto a esta fase, es cierto que se ha conseguido desplegar una aplicación web con la que se
prueba el funcionamiento del IS (con la ayuda del componente WSO2 Application Server), pero no se
ha dispuesto del tiempo suficiente para realizar un prototipo lo suficientemente complejo como para
poner en valor todo el trabajo desarrollado y poderlo apreciar visualmente.
Para sintetizar un poco todos los objetivos que se han marcado en el proyecto y su órden de realización, a
continuación se presenta un esquema visual y sencillo general.
Recopilación de
Información
Instalación y análisis del IS
Creación de Dialecto en
el IS
Creación de políticas
XACML en IS
Elaboración de un
escenario de prueba
Ilustración 1. Fases del proyecto
5
4 Organización del documento
En este apartado se va a proceder a detallar la organización y presentación de la información de este
documento.
Primeramente, se realizará una introducción al escenario o entorno en el que nos vamos a ubicar durante todo
el desarrollo del trabajo en el apartado Estado de la técnica. En él se describirán resumidamente las
características actuales de entorno empresarial y tecnológico en el que nos ubicamos actualmente e
información acerca de la utilidad y actualidad de la tecnología de la que vamos a hacer uso.
Tras esto, nos encontraremos con la definición del grueso del proyecto en el apartado de Desarrollo del
proyecto. En este apartado se detallarán los conceptos y conocimientos previos que debemos manejar para
entender perfectamente las herramientas que vamos a utilizar, el funcionamiento y gestión de las mismas y los
pasos que se han seguido (guía de uso o metodología) para llevar a cabo el proyecto.
Después de este apartado, vendría el apartado Conclusiones. En él se realizará una reflexión acerca de los
resultados obtenidos, la utilidad del sistema implementado, se indicarán las ventajas e inconvenientes que
presenta el sistema desarrollado y se propondrán futuras líneas de desarrollo y mejoras. Por último, tendremos un par de apartados relacionados con información complementaria sobre las referencias
y recursos que han sido manejados en la realización del proyecto. Estos apartados son los de Bibliografía y
Anexos.
6
7
ESTADO DE LA TÉCNICA
1 Contexto
n la actualidad el almacenamiento y procesamiento de datos de forma remota o distribuida se ha
convertido en uno de los campos de investigación más relevante y rentable del mundo. En
relativamente poco tiempo, se ha logrado que cualquier recurso almacenado y conectado a la red
sea accesible y gestionable desde cualquier punto del planeta y por cualquier usuario, empresa o entidad
autorizados.
De la mano de esta evolución en la accesibilidad y gestión de datos o servicios ha ido el desarrollo de los
mecanismos de autenticación y autorización (seguridad), ya que, aunque es relevante poder contar con un
modelo/sistema que permita disponer de arquitecturas con datos y servicios desacoplados (facilitando el
diseño, despliegue y gestión de servicios grandes y complejos) también es necesario garantizar la
seguridad de la información, debiendo gestionar adecuadamente los permisos de acceso, políticas o
derechos y teniendo en cuenta el grado de importancia y el nivel de protección que se les debe asignar.
Uno de los terrenos en el que es habitual el uso de sistemas distribuidos y en el que la seguridad,
privacidad y fiabilidad de la información resulta de vital importancia es dentro del ámbito médico o de la
salud ([1] , [2] y [3] ). Dentro de cualquier tipo de centro hospitalario, clínica o centro sanitario se debe
respetar un marco legal y normativo de obligado cumplimiento que asegura la confidencialidad,
integridad y disponibilidad de los datos sensibles de los distintos usuarios y empleados del entorno.
Adicionalmente, de cara al cliente, el sistema distribuido debe funcionar como si fuera una única entidad,
ocultando toda su complejidad y el hecho de que sus recursos estén dispersos en distintas máquinas y
localizaciones.
En la mayoría de los casos tener un sistema de este tipo implica que, en su conjunto, el sistema se vuelve
heterogéneo, es decir, que cada proceso ejecutado o dato almacenado se ubica en un determinado equipo
con su correspondiente hardware y software. Es aquí donde surge la imperiosa necesidad de realizar un
diseño lo más independiente y genérico posible (donde la naturaleza hardware y software de los equipos
donde se vaya a implementar el sistema nos condicione lo mínimo posible).
Existen muchos tipos de empresas que aportan una gran variedad de soluciones a esta cuestión, sobre
todo basadas en “lógicas de intercambio de información entre aplicaciones”, las cuales permiten a los
desarrolladores de sistemas abstraerse de gran parte de los problemas relacionados con el funcionamiento
de las arquitecturas distribuidas, haciendo transparente el hecho de que varias partes o módulos de un
mismo sistema se encuentren desplegados en distintos equipos, que se ejecuten en un sistema operativo u
otro, etc., todo esto sin provocar la pérdida de ninguna funcionalidad o mermar el rendimiento que
presenta el conjunto del sistema.
Es en este entorno donde se enmarca WSO2, una empresa fundada en 2005 que ofrece un completo set de
herramientas de código 100% abierto (Open Source) que permiten a particulares y empresas construir una
arquitectura orientada a servicios (SOA) completa.
Dentro de la suite de productos que ofrece WSO, encontramos un componente muy interesante, el
Servidor de Identidad (Identity Server, recordemos, en adelante IS). El IS es la espina dorsal que permite
conectar y gestionar múltiples identidades a través de distintas aplicaciones, APIs, la Cloud, dispositivos
móviles y dispositivos IoT, independientemente de las normas en las que se basen. Dicho servicio se
puede desplegar localmente o directamente en la nube y tiene características muy útiles relacionadas con
la seguridad, como la de propagar identidades a través de fronteras geográficas y comerciales o como la
del control de acceso a recursos en un entorno de empresarial conectado.
E
8
2 Conceptos previos
2.1 XACML Y SAML
l control de acceso a sistemas, servicios o recursos (en general) es el punto principal en el que se basa
este documento y precisamente XACML es la clave para llevarlo a cabo. Estamos ante un lenguaje
basado en el estándar XML diseñado para proveer políticas de seguridad y derechos de acceso a la
información. Como tal, permite definir cómo es la arquitectura de intercambio de mensajes de autorización y
un modelo para organizar y almacenar la información de autorización.
Un hecho muy interesante es que XACML impone una estructura base con la suficiente flexibilidad para que
cada sistema exprese las políticas de autorización de la forma más conveniente a su dominio.
XACML define un sistema de autorización basado en cuatro subsistemas, cada uno con una función bien
definida. Estos sistemas colaboran entre sí para cumplir las funciones impuestas por el sistema de autorización
como un todo (la norma llama a cada uno de estos elementos “Points”):
Punto de Administración de Política (PAP): punto donde se gestionan y administran las políticas.
Hace posible que las políticas se puedan almacenar y recuperar del Repositorio de Políticas. Puede ser
desde un simple editor XML hasta un sistema encargado de encapsular un lenguaje de políticas
propietario en la forma de un lenguaje XACML.
Punto de Decisión de Política (PDP): recibe las peticiones de autorización y devuelve la decisión
tomada en función de la información contenida tanto en la petición como en los PIPs y en función de
la evaluación de las políticas XACML correspondiente.
Punto de Control de Política (PEP): es el punto que intercepta las peticiones de acceso a recursos y
las redirige al PDP para obtener una decisión de autorización. Tras de obtener dicha decisión (positiva
o negativa), el PEP permite o deniega el acceso a la entidad que hizo la petición según convenga.
Punto de Información de Política (PIP): repositorio de datos/información de los atributos
disponibles para evaluar las políticas y tomar decisiones de autorización.
A continuación se muestra un esquema donde se recogen los elementos anteriormente nombrados, su
disposición en un escenario genérico y las relaciones existentes entre los mismos:
E
Imagen 2. Esquema simplificado de un Sistema de control de Acceso
9
Sin embargo, XACML no define ningún aspecto del intercambio de información entre entidades, sólo está
definiendo un tipo de lenguaje o estructura de comunicación. Necesitamos hacer uso de algún protocolo que
nos permita enviar y recibir ese tipo de estructuras. SAML es nuestra solución.
SAML es un estándar abierto de intercambio de información de autenticación y autorización entre diferentes
dominios o entidades a través de la red y que está basado en protocolos que consideran intercambios de
mensajes XML.
SAML no determina cómo definir políticas de acceso, pero dentro del protocolo que define, contempla la
posibilidad de intercambiar mensajes de autorización, los cuales podrían contener estructuras basadas en
XACML.
Normalmente las entidades que intervienen en el intercambio de mensajes son un proveedor de identidad y un
proveedor de servicio (en nuestro caso, ambos proveedores se encontrarán recogidos en un mismo
componente y trabajaremos como si todo estuviera integrado).
A continuación se muestra un esquema de un escenario genérico en el que se aprecia el intercambio de
información entre varios proveedores haciendo uso de SAML:
Imagen 3. Esquema de uso de SAML
10
2.1 SOAP
2.1.1 Introducción
SOAP (Simple Object Access Protocol) ([9] , [10] , [11] y [12] ) es un protocolo (basado en el uso de XML)
utilizado para el intercambio de información estructurada y tipada en un entorno descentralizado y distribuido.
Define un mecanismo para expresar la semántica utilizada por las aplicaciones proporcionando un modelo de
empaquetado de mensajes modular y un mecanismo de codificación de los datos en módulos (esto permite a
SOAP ser usado en una larga variedad de sistemas).
SOAP consta básicamente de tres bloques:
El envoltorio (envelope): define un esquema para describir lo que va
incluido en un mensaje, cómo procesarlo, quien tiene que procesarlo
y si es opcional u obligatorio.
Las reglas de codificación: definen un mecanismo de serialización2
que puede ser usado para intercambiar instancias de tipos de datos
definidos por las aplicaciones.
La representación RPC: define una metodología que puede ser
usada para representar invocaciones a procedimientos remotos y sus
respuestas.
2.1.2 El modelo de intercambio de mensajes SOAP
Los mensajes SOAP son fundamentalmente unidireccionales (de emisor a receptor), aunque a menudo se
combinan para implementar patrones como el de solicitud/respuesta (request/response). Cada vez que una
aplicación recibe un mensaje SOAP debe procesarlo siguiendo las pautas que se indican a continuación (en
este orden):
Primero debe identificar todas las partes del mensaje que están destinadas a dicha aplicación.
Después debe verificar si todas las partes obligatorias detectadas en el paso anterior son soportadas
por la aplicación y, en caso afirmativo, debe procesarlas debidamente. Si este no es el caso, entonces
se debe descartar el mensaje. Adicionalmente, el procesador puede ignorar partes opcionales
identificadas en el paso anterior sin afectar el resultado del procesamiento.
Por último, si la aplicación SOAP no es el destino final del mensaje, se deben eliminar todas las partes
identificadas en el primer paso y reenviar el mensaje al siguiente destino.
En el caso concreto de este trabajo, nos interesa entender únicamente el uso de SOAP para comunicar
aplicaciones, realizando invocaciones RPC e implementando el patrón solicitud/respuesta, por lo cual el
comportamiento es similar al de una arquitectura cliente servidor, donde el proceso es iniciado por el cliente y
el servidor responde con un mensaje determinado.
Este tipo de comunicación se basa en un sistema de mensajes SOAP síncronos, codificados en XML, que son
transportados por HTTP.
Imagen 4. Intercambio de mensajes SOAP
2 Proceso de codificación de un objeto en un medio de almacenamiento con el fin de transmitirlo a través de una conexión en red como una serie de bytes o en un formato humanamente legible como XML o JSON.
11
En la figura anterior se observa un ejemplo de arquitectura básica de un sistema construido sobre SOAP y los
mensajes que definen la interacción entre la aplicación cliente y la aplicación servidor. Generalmente la
aplicación cliente envía un mensaje (REQUEST vía HTTP), el cual, al ser recibido por la aplicación servidor,
genera una respuesta (RESPONSE) que es enviada a la aplicación cliente vía HTTP.
2.1.3 Mensaje SOAP
Para el caso que nos ocupa, tanto los mensajes REQUEST como RESPONSE se transportarán en mensajes
HTTP, pero hay que tener en cuenta que en caso de usar cualquier otro protocolo de transporte no cambia el
contenido del mensaje, el cual está codificado en XML. La parte XML de los mensajes tiene la estructura que
se muestra en la siguiente figura.
Los mensajes SOAP están codificados en XML y constan de una sección
denominada envoltorio o envelope (obligatoria), la cual está compuesta de una
sección denominada cabecera o header (opcional) y de una sección denominada
cuerpo o body (obligatoria). A continuación se van a detallar todas y cada una de
las partes que hemos indicado anteriormente para enter mejor la estructura de los
mensajes y su funcionamiento.
2.1.3.1 SOAP Envelope
Esta construcción sintáctica de nombre envoltorio o envelope contiene al resto del documento XML, debiendo
estar presente siempre y ser la primera sección del mensaje. Define todos los espacios de nombres
Ejemplo 2. Mensaje SOAP embebido en una respuesta HTTP
13
2.2 LDAP
2.2.1 Introducción
A grandes rasgos, LDAP (Lightweight Directory Access Protocol) ([13] , [14] , [15] , [16] , [17] y [18] ) es un
protocolo que define un método para la gestión de datos de un directorio. Entre otras cosas, detalla cómo se
representan los datos en el servicio de directorio (Data/Information Model), cómo se cargan los datos
(importan) o cómo se salvan (exportan) desde un servicio de directorio (usando archivos LDIF).
Concretando un poco más, LDAP define cuatro modelos principales:
Modelo de Información o Modelo de Datos (Information Model): modelo que define cómo se
presenta la información/datos en el directorio.
Modelo de nombrado (Naming Model): modelo que define todas las etiquetas (sintaxis) que
podemos encontrar el directorio.
Modelo funcional (Functional Model): cuando leemos, buscamos, escribimos o modificamos el
directorio, estamos utilizando este modelo.
Modelo de seguridad (Security Model): modelo que define ciertas condiciones o criterios de control
sobre los datos almacenados en el directorio (quién quiere acceder a los datos, qué se quiere hacer con
los datos, cuándo se quiere accede a los datos, etc.).
El ámbito del estándar LDAP se representa en el diagrama mostrado a continuación. Las flechas de color rojo
están definidas dentro del protocolo (en varias RFCs que define LDAP), mientras que las flechas de color
negro y los procesos que ocurren dentro de los distintos cuadros de colores se localizan fuera del ámbito del
estándar.
Antes de seguir explicando las características de LDAP, hay que recalcar dos conceptos fundamentales que
resumen su funcionamiento y finalidad:
Aunque LDAP no define cómo se almacena la información, ya que sólo define cómo acceder a ella,
muchas de las implementaciones LDAP usan bases de datos estándar (como OpenLDAP) cómo
forma de almacenamiento de la información (Back-End DataBase).
Cuando nos comunicamos con un servidor LDAP no podemos saber de dónde proceden los datos, de
hecho, el verdadero objetivo del estándar es ocultar este nivel de detalle a usuarios y aplicaciones
externas. En teoría, la información puede provenir de una o más bases de datos locales o de uno o
muchos servidores X.500.
Imagen 5. Esquema de funcionamiento de LDAP
14
2.2.2 Estructura del árbol de objetos
En esta sección vamos a intentar definir brevemente la esencia o núcleo de LDAP.
Los datos/información de un sistema LDAP se representan como una jerarquía de objetos, cada uno de los
cuales se denomina entrada. La estructura en árbol resultante se denomina Árbol de Información de Directorio
(Directory Information Tree – DIT) y la parte más alta del árbol (el inicio) se denomina raíz (root).
Cada entrada del árbol tiene una entrada padre (objeto), salvo la raíz, y cero o más entradas hijas (objetos de
nuevo). Cada entrada hija es hermana del resto de entradas hijas de su padre.
Por otro lado, cada entrada está compuesta de (es una instancia de) uno o más objectClasses. Cada objectClass
contiene cero o más atributos. Los atributos, a su vez, tienen nombres (y en ocasiones abreviaturas o alias) y
por lo general contienen información (en apartados posteriores se explicará con mayor grado de detalle lo que
es un objectClass y lo que son los atributos en LDAP).
Las características (propiedades) de los objectClasses y sus atributos son descritos con definiciones ASN.14
A continuación se muestra un diagrama en el que se ilustran las relaciones y características mencionadas
anteriormente:
Explicación detallada:
1. Cada entrada (1) está compuesta de uno o más objectClasess (2)
2. Cada objectClass (2) tiene un nombre y contiene una serie de atributos (su definición identifica
atributos que debe tener obligatoriamente y atributos que puede tener de forma opcional).
3. Cada atributo (3) tiene un nombre, contiene información y es miembro de uno o más objectClass(es)
(2).
4. Cuando el árbol (DIT) está poblado, cada entrada estará identificada unívocamente (en relación con su
entrada padre) en la jerarquía en función de la información que contiene (en sus atributos, que a su vez
están contenidos en sus objectClass(es)).
De cara al exterior de LDAP (usuarios, aplicaciones, etc.) los elementos realmente visibles son las entradas y
los atributos de dichas entradas, ya que los objectClasses sólo aportan información de control o de estructura.
Por ejemplo, si tuviéramos la entrada “MiCoche”, ésta podría estar definida por los objectClasses “Carac.
Técnicas” (con los atributos “cilindrada”, “peso” y “consumo”) y “Carac. Visuales” (con los atributos “color”,
“marca”, “modelo” y “mátricula”). La entrada “MiCoche” estaría caracterizada por dichos atributos.
4 Abstract Syntax Notation One (más conocido como ASN.1) es un lenguaje para definir estándares independientemente de la implementación (es el lenguaje que emplean los autores de estándares). ASN.1 facilita la comunicación entre profesionales al ofrecer un lenguaje común para describir un estándar (se define en las recomendaciones X.209 y X.690 de la ITU-T).
Imagen 6. LDAP DIT Information/Data Model (I)
15
2.2.3 Object Classes
Los objectClasses son contenedores de atributos que tienen un nombre único (cuando hablamos de único, no
solo nos referimos a único en el ámbito de los objectClass, sino también en todo el ámbito de nombres LDAP,
de forma que si, por ejemplo, existiera un objectClass con nombre “persona” no podría existir un atributo con
nombre “persona” y vicecersa) y que se describen mediante el uso de definiciones de ASN.1.
Hay un número considerable de objectClasses predefinidos, cada uno de los cuales contiene un conjunto de
atributos idóneos o adecuados para prácticamente todas las implementaciones LDAP más comunes.
Las principales características de los objectClasses son las siguientes:
Los objectClasses detallan qué atributos debe definirse obligatoriamente (deben de tener un valor
asignado obligatoriamente) y cuales son opcionales.
Todo objectClass tiene un tipo que lo define, puediendo ser structural, auxiliary o abstract (es
obligatorio que todo objectClass tenga uno de estos tipos). Cada entrada puede implementar un, y sólo
un, objectClass de tipo structural y puede implementar cero o más de tipo auxiliary o abstract.
Un objectClass puede ser parte de una jerarquía (puede tener un padre), en cuyo caso hereda todas las
características de los objectClass(es) de su padre (incluyendo todos los atributos contenidos en ellos).
Imagen 7. LDAP DIT Information/Data Model (II)
2.2.4 Atributos
Las principales características de los atributos son:
Todos los atributos son miembros de uno o más objectClass(es).
Cada atributo define el tipo de dato (syntax) que puede contener o almacenar.
Los atributos pueden ser parte de una jerarquía, en cuyo caso el atributo hijo hereda todas las
características del atributo padre.
Los atributos pueden ser opcionales (may) u obligatorios (must) tal y como se describe en la
definición ASN.1 para los objectClass a los que pertenecen (un mismo atributo puede ser obligatorio
en un objectClass y opcional en otro).
Los atributos pueden almacenar uno o varios valores. Esto quiere decir que, dentro de una entrada u
objectClass, podemos tener un mismo atributo instanciado una única vez o varias veces. Por ejemplo,
cuando una persona tiene varios correos electrónicos, necesitaremos varias instancias del atributo
asociado al correo electrónico.
Los atributos tienen nombres únicos (y en ocasiones, abreviaturas o alias). Por ejemplo, el atributo
commonName tiene un nombre abreviado denominado cn (ambos pueden ser utilizados para
referenciar al mismo atributo).
16
En cada nivel de la jerarquía, la información contenida en uno o varios atributos puede ser utilizada
para identificar unívocamente la entrada (siempre que el atributo o la combinación de ellos sea única).
El valor del atributo (o atributos) seleccionado (para identificar unívocamente la entrada respecto de
su padre) es llamado atributo de nombrado o RDN (Relative Distinguished Name), y nunca podrá
estar repetido (este comportamiento sería idéntico al de una estructura de directorios normal y
corriente de cualquier S.O, la tupla “nombre-tipo” de cada elemento contenido dentro de una carpeta
es lo que le diferencia del resto y, además, dicho tupla no puede estar repetida en ningún caso).
2.2.5 Esquemas
Un esquema LDAP no es más que un conjunto de objectClasses (generalmente similares) que agrupamos
convenientemente en función de las características de los elementos que queramos definir en el directorio.
La única regla es que todo atributo u objectClass usado en una implementación LDAP debe de estar definido
en un esquema, y dicho esquema debe ser conocido por el servidor LDAP por un procedimiento de
configuración u opción. Por ejemplo, en OpenLDAP los esquemas instalados se localizan en la ruta
“cn=schema, cn=config” y todo esquema adicional que queramos instalar puede ser añadido en dicha ruta.
En la siguiente imagen vemos una representación de lo que sería un esquema genérico.
Imagen 8. Representación de esquemas LDAP compuestos de objectClasses y atributos
2.2.6 Árbol de directorios
Una vez ya tenemos toda nuestra información insertada en el árbol (DIT) ahora tenemos que entender cómo
manejarla convenientemente.
Para empezar, vamos a detallar varios conceptos de la terminología esencial y necesaria para poder entender
cómo gestionar debidamente un directorio.
Anteriormente, hemos hablado de que cada entrada debe ser unívocamente identificable (respecto de su padre)
usando, por ejemplo, un AVA5 (Attribute Value Assertion) individual o múltiple (“cn=Ernesto” o “cn=Enrique
Gil”). Pero además, tenemos que tener en cuenta que la ruta hasta cualquiera de las entradas de cualquier nivel
del árbol debe ser única también, por lo que tendremos buscar la forma de utilizar todas las entradas únicas
individualmente (respecto de sus padres) para identificar la ruta completa hasta la entrada final.
Así, supongamos que el AVA “cn=Robert Smith” identifica una entrada unívocamente respecto de su padre
(puede actuar de RDN). El valor que identificará la ruta desde la raíz (root) del árbol (DIT) hasta dicha entrada
será la suma de todos los RDNs (unidos por comas en orden ascendente y de izquierda a derecha) que haya por
el camino. Este conjunto de RDNs que identifica unívocamente la ruta hasta la entrada concreta identificada
por el AVA que hemos tomado de ejemplo se denomina DN (Distinguish Name).
Resumiendo, un DN describe la ruta hasta cualquier entrada del DIT (partiendo desde la raíz).
Por último, y antes de seguir detallando los conceptos comentados en los párrafos anteriores, mencionar que,
igual que hemos usado el AVA “cn=Robert Smith”, podríamos haber usado cualquier otro (o combinación de
otros) que sirviera como identificador único respecto de su padre (RDN).
5 Un Attribute Value Assertion (AVA) es una combinación de la descripción de un atributo y del valor que toma el propio atributo. El “assertion value” se combina con una regla de coincidencia con el fin de hacer la determinación (en nuestro caso, un símbolo “=”). De esta forma, un RDN podrá estar formado por uno o varios AVAs.
17
En los diagramas expuestos a continuación se explican mejor los conceptos de DN y RDN para que acabemos
de entender perfectamente cuál es su función y su uso.
Para “navegar” por el árbol de directorios podemos definir una ruta (DN) para el lugar donde está la
información que queremos gestionar (Ej: cn=Robert Smith, ou=people,dc=example, dc=com) o también
podemos definir una ruta (DN) hacia el sitio donde pensamos o creemos que nuestra información está
almacenada (Ej: ou=people,dc=example,dc=com) y después realizar búsquedas concretas del atributo que
queramos (atrribute=value) para encontrar nuestra entrada (o entradas) objetivo.
En el ejemplo anterior, se ha seleccionado el atributo cn (commonName) como nuestro RDN porque es único
en ese nivel de la estructura de directorios. Esto nos proporciona el siguiente DN:
Pero, tal y como hemos explicado anteriormente, y como se muestra en la imagen anterior, también podríamos
haber seleccionado el atributo uid (userID) como nuestro RDN porque es único igualmente, resultando el
siguiente DN igualmente válido:
DN: uid=rsmith, ou=people, dc=example, dc=com
Imagen 9. Diagrama explicativo del uso de RDNs y DNs (I)
Imagen 10. Diagrama explicativo del uso de RDNs y DNs (II)
AVA AVA AVA
AVA AVA AVA AVA
AVA
18
2.3 Estándares OASIS
Enabling the interoperable exchange of healthcare privacy policies, consent directives, and authorizations
- www.oasis-open.org -
OASIS es un importante consorcio internacional sin ánimo de lucro centrado en el desarrollo, la convergencia
y la adopción de estándares abiertos para la sociedad de información global.
Los miembros de OASIS representan gran parte del mercado público y privado, de los usuarios y de las
personas influyentes del sector tecnológico. El consorcio cuenta con más de 5.000 miembros en representación
de más de 600 organizaciones y de más de 65 países.
OASIS busca promover un consenso en la industria, elaborando estándares a nivel global para temas
relacionados con la seguridad, el Internet de las cosas (IoT), la computación en la nube (cloud computing), la
energía, las tecnologías de contenido (content technologies), la gestión de emergencia, etc. Estos estándares
ofrecen un gran potencial para reducir costes, estimular la innovación y crecimiento de los mercados globales
y para proteger el derecho a la libre elección de uso de la tecnología.
Concretando un poco más, uno de los comités de OASIS se centra en la realización de estándares relacionados
con el ámbito de la salud, el Comité Técnico XSPA. Éste comité ha centrado sus esfuerzos en desarrollar una
segmentación de datos y una clasificación de perfiles de seguridad relacionados con el ámbito de la salud en
armonía con HL76 ([4] ) e IHE7 ([5] ), estandarizando la forma en la que los profesionales de la salud,
hospitales, farmacias y compañías de seguros intercambian políticas de privacidad, directivas de
consentimiento y autorizaciones internamente y entre ellas.
Es en este punto es donde entra en juego el estándar que hemos tomado como referencia para realizar este
proyecto, el estándar OASIS Cross-Enterprise Security and Privacy Authorization (XSPA) TC. Éste estándar
especifica una semántica/sintaxis y vocabulario comunes (que podemos encontrar en los distintos estándares
OASIS ya existentes) que dan soporte a una serie de métodos fiables y auditables relacionados con la
confirmación de identidades y con la gestión de políticas (su aplicación, su ciclo de vida, etc.).
Se puede consultar toda la información relacionada con el estándar XSPA de OASIS accediendo directamente
al documento oficial de OASIS ([20] ).
También se puede disponer de más información sobre OASIS y todos los estándares con los que cuenta en su
página web oficial ([19] ).
6 Health Level Seven (HL7) es una organización desarrolladora de estándares (SDOs) cuyo principal objetivo es definir y especificar un lenguaje común para el intercambio de información clínica y administrativa entre sistemas informáticos del ámbito de la salud. Existen algunos estándares dentro de HL7 que tienen otros focos, pero este aspecto es quizás el más importante dentro de HL7. 7 Integrating the Healthcare Enterprise (IHE) es una organización sin ánimo de lucro cuya finalidad es mejorar la comunicación entre los distintos sistemas de información sanitarios y/o promover la adopción coordinada de estándares internacionales para lograr la interoperabilidad de los diferentes sistemas y aplicaciones utilizados en el ámbito sanitario.
Comprehensive and open platform for your connected business.
- WSO2 –
Desde la última década WSO2 encabeza un movimiento global basado en el uso de sus componentes como
solución empresarial rentable, ágil y resolutiva. El conjunto de componentes free source y basados en
estándares abiertos que ofrece se extiende prácticamente por todos los dominios tecnológicos existentes dentro
del mercado actual (utilizando una arquitectura orientada a servicios, SOA).
En la siguiente imagen se muestra una representación esquemática de los distintos ámbitos en los que WSO2
cuenta con uno o varios componentes.
Imagen 11. Ámbitos tecnológicos WSO2
La plataforma que ofrece WSO2 es altamente extensible y personalizable, pudiendo interactuar con
componentes basados en estándares tanto existentes como nuevos, integrándose con una amplia variedad de
aplicaciones y permitiendo un fácil acceso a bases de datos y sistemas de archivos. A su vez, permite que los
desarrolladores puedan ampliar la plataforma, personalizar el código y utilizar cualquier modelo de
programación para implementar nuevas funcionalidades.
Durante el transcurso de toda la memoria hay que tener en cuenta que, aunque sólo tratemos con un par de
componentes de WSO2 de forma local, en un entorno profesional real éstas formarían parte de una
arquitectura orientada a servicios (SOA), colaborando con otros módulos y sistemas de forma activa, pudiendo
alojarse en cualquiera de los equipos del sistema e incluso duplicarlos.
Gran parte de la culpa de que el conjunto de componentes funcionen correctamente la tiene el middlware8
Carbon ([24] ), el núcleo básico sobre el que se sustentan todos los softwares de la suite que ofrece WSO2. Su
arquitectura basada en componentes le permite desplegar sólo aquellos procesos o recursos que necesita y
cuando los necesita, permitiendo adaptar automáticamente la actividad de negocio en función de la evolución
del entorno.
8 Un middleware es un software o conjunto de componentes desarrollados para integrar aplicaciones y/o plataformas (Ej: Servidor de Transacciones o Servidor de Aplicaciones) en un ambiente donde interactuan distintos tipos de tecnologías, encargándose por sí mismo de comunicar e integrar todos los datos de diversa índole.
20
WSO2 Carbon proporciona una plataforma integrada y agrupada en componentes que se adapta a las
necesidades específicas de cualquier proyecto TI o TIC (tanto en local como en la nube).
100% código abierto y basado en estándares, Carbon permite a los desarrolladores gestionar rápidamente los
procesos de negocio, crear aplicaciones y desarrollar servicios utilizando WSO2 Developer Studio y una
amplia gama de servicios técnicos y de negocio.
Además, esta plataforma basada en la arquitectura OSGi9 incluye más de 175 componentes y el núcleo de su
framework funciona como si fuera un "Eclipse para servidores”, incluyendo características comunes
compartidas por todos los productos WSO2, como son el registro integrado, la gestión de usuarios y de
transporte, los servicios de seguridad o de inicio de sesión, mecanismos de clustering10, caching11 y
coordinación o la interfaz gráfica de usuario.
Imagen 12. Esquema genérico de la plataforma Carbon WSO2
Si se desea más información al respecto, se insta al lector a consultar la página web oficial de WSO2 donde se
detalla perfectamente el funcionamiento y las características del funcionamiento de Carbon.
Para tener una idea mejor del conjunto de soluciones que ofrece WSO2, se muestra a continuación un esquema
de varios de los distintos componentes de los que dispone actualmente la suite de WSO2 y todas las posibles
interacciones existentes entre ellos (en función de nuestras necesidades o prioridades podemos elegir realizar
varios tipos de configuraciones distintas).
9 OSGi son las siglas de Open Services Gateway initiative, creado en marzo de 1999, con el objetivo de definir especificaciones abiertas de software que permitan diseñar plataformas compatibles con vistas a proporcionar múltiples servicios. 10 División de un conjunto de datos en grupos de objetos similares que trabajan como uno sólo y aumentan la capacidad de procesamiento y el rendimiento. 11 Almacenamiento temporal de los datos frecuentemente accedidos más cerca del solicitante de los mismos.
21
Imagen 13. Visión general de la suite de productos de WSO2
De entre todos los productos mostrados anteriormente, los más utilizados actualmente son:
Enterprise Service Bus (ESB): El bus de servicios de empresa es pieza clave en cualquier
arquitectura SOA, actuando como bus de integración común y como núcleo de la plataforma SOA.
Business Activity Monitor (BAM): Permite monitorizar la actividad de negocio.
Data Service Server (DSS): Herramienta que transforma una base de datos en un servicio web.
WSO2 Developer Studio: es un entorno de desarrollo, basado en Eclipse, para la creación y
despliegue de aplicaciones y componentes en la plataforma SOA.
Identity Server (IS): herramienta que nos permite gestionar la seguridad de los servicios o recursos
utilizados. Es el principal componente que usaremos en este proyecto.
Message Broker (MB): herramienta que posibilita la comunicación asíncrona entre aplicaciones y la
publicación de mensajes a suscriptores.
Aplication Server (AS): servidor de aplicaciones que proporciona una solución completa para el
alojamiento (hosting), despliegue y gestión de aplicaciones y servicios. Este componente también será
utilizado en este proyecto.
Se puede encontrar una definición extensa y perfectamente detallada de cada uno de los productos mostrados
en la Imagen 13. Visión general de la suite de productos de WSO2 en la página web oficial de WSO2 por si el
lector desea ahondar en las características o funcionalidades de alguno de ellos.
22
En el siguiente gráfico se representa el resultado de una comparativa entre plataformas SOA open source, en la
cual se analizan aspectos tales como la capacidad de integración, el comportamiento en un entorno productivo,
la asequibilidad de los productos, los adaptadores disponibles y otras características. Podemos apreciar como
WSO2 ofrece el producto más equilibrado y completo de entre el resto de plataformas del mercado
actualmente.
Imagen 14. Comparativa de plataformas SOA
Realizada ya la presentación formal de la suite de productos ofrecidos por WSO2, en los subapartados
posteriores vamos a proceder a introducir los dos principales con los que se ha trabajado en este proyecto.
Primero vamos a hablar del Servidor de Identidad (Identity Server), que es el núcleo de nuestro proyecto y la
clave para desarrollar todas las funcionalidades de control de acceso que queremos implementar. Se realizará
una explicación detallada de sus características, su funcionamiento, la arquitectura que tiene y las posibilidades
que ofrece.
Tras esto, se expone una breve introducción al Servidor de Aplicaciones (Aplication Server) que, aunque no
es objeto fundamental de estudio en este proyecto, resulta bastante interesante y útil para llevar a cabo un
escenario de prueba del sistema localmente. Se realizará una explicación a grandes rasgos sin entrar en muchos
detalles acerca de sus características de funcionamiento, la arquitectura que presenta y de las posibilidades que
ofrece.
Por último, mencionar que en el apartado correspondiente al método y desarrollo del proyecto se realizará una
explicación detallada de las herramientas y funcionalidades utilizadas de ambos componentes de forma clara y
concisa mediante el uso de capturas de pantalla o imágenes que permitirán al lector conocer perfectamente el
camino seguido hasta construir el entorno de prueba al completo.
23
3.1 Introducción al Identity Server
Es el servidor de gestión de identidades y derechos de código abierto por excelencia.
- Johann Dilantha Nallathamby, WSO2 Identity Server 5.0.0 – Identity & Access Management Redesigned –
omo ya se comentó brevemente en los apartados Motivación y Contexto, el objeto de esta proyecto es
adaptar el Servidor de Identidad ([25] y [26] ) que ofrece WSO2 en su suite de productos “open
source” al ámbito de la salud (tomando como referencia el estándar OASIS explicado en el apartado
Estándares OASIS), de forma que pudiera llegar a ser utilizado en un entorno sanitario real de forma
perfectamente funcional.
El Servidor de Identidad de WSO2 nos permite gestionar y administrar identidades y autorizaciones dentro de
un entorno controlado, facilitando la seguridad del sistema, el intercambiando y la gestión de múltiples
identidades de distintas aplicaciones. Permite a programadores, analistas o arquitectos software mejorar la
experiencia del cliente a través de un entorno seguro de inicio de sesión único (Single Sign On, SSO),
reduciendo el tiempo de provisionamiento de identidades y garantizando interacciones seguras a través de la
red.
Las principales características que ofrece (en la versión 5.0.0) son:
Autenticación: es capaz de almacenar usuarios y credenciales en distintos tipos de almacenamientos
(“user stores”), de leer directamente dicha información de un servidor LDAP externo (Active
Directory) o de una base de datos externa y verificar o enfrentar dichos datos con los datos acceso de
cualquier entidad al sistema.
Autorización: el IS incluye las funcionalidades de PDP y PAP. Esto nos permite definir
reglas/políticas de autorización y definir qué condiciones se deben cumplir para que un
usuario/entidad pueda acceder a un determinado recurso o servicio (identificado con una url).
Federación: permite que una aplicación autentique contra distintos proveedores de credenciales, es
decir, permite englobar dentro de una misma aplicación usuarios de distintos proveedores de
identidades heterogéneos como por ejemplo Facebook, Google o STS.
Provisionamiento: el IS puede hacer uso de entidades o sistemas externos para enviar peticiones y
recibir solicitudes de provisionamiento de determinados servicios. De esta forma, aplicaciones
externas pueden hacer uso de las características y funcionalidades del servidor de forma cómoda y
sencilla y el propio IS puede externalizar funcionalidades según le convenga.
Gestión de identidades: gestión del ciclo de vida de las credenciales de usuarios y entidades.
C
Imagen 15. Tabla de características del IS
24
A continuación se muestra la arquitectura interna que presenta el IS en su versión 5.1.0. En la imagen se
pueden apreciar a grosso modo las principales funcionalidades y posibilidades que ofrece el este servicio. Tras
esta, se realiza una introducción a las principales características que podemos encontrar en dicha arquitectura.
Imagen 16. Arquitectura genérica del IS
- Proveedor de servicios (Service Provider o SP): es una entidad que ofrece servicios web. Los proveedores
de servicio se basan en un proveedor de identidad de confianza (IdP) para la autenticación y autorización. En
este caso, nuestro servidor de identidad actúa como IdP y hace la tarea de autenticación y la autorización al
usuario del proveedor de servicios. Salesforce y Google Apps son ejemplos de proveedores de servicios.
- Autenticador de entradas (Inbound Authenticator o IA): es el encargado de manejar todas las solicitudes
entrantes en el sistema. Las solicitudes que maneja son las siguientes:
SSO12 SAML: como ya se definió en apartados anteriores de esta memoria, es un estándar abierto
OASIS para representar e intercambiar los datos de identidad de usuario y la autenticación entre varias
partes. SAML proporciona la capacidad de inicio de sesión único basado en la web.
OAuth: también conocido como Open Authorization, es un protocolo que permite flujos simples de
autorización para sitios web o aplicaciones. OAuth permite a un usuario del sitio A compartir su
información del sitio A (proveedor de servicio) con el sitio B (llamado consumidor) sin compartir
toda su identidad.
Pasivas STS: el servicio de tokens de seguridad (Security Token Service o STS) es un software
basado en el uso de un proveedor de identidad responsable de emitir tokens de seguridad,
especialmente los de software, como parte de un sistema de identidades basado en atributos (claims).
OpenID: es un estándar de identificación digital descentralizado, con el que un usuario puede
identificarse en una página web a través de una URL (o un XRI en la versión actual) y puede ser
verificado por cualquier servidor que soporte el protocolo.
12 Procedimiento de autenticación SSO (Single Sign On) habilita a un usuario a acceder a varios sistemas distintos con una sola instancia de identificación.
25
- “Esquema/entorno de Autenticación” (Authentication Framework): la gestión de claims es un aspecto
clave dentro del Servidor de Identidad que ayuda a mapear los claims locales con los claims del proveedor de
servicios (service provider) y viceversa.
El provisionamiento “Just-in-Time” permite crear usuarios “al vuelo” sin tener que crear cuentas de usuario
con antelación. Por ejemplo, si hemos añadido recientemente un usuario a nuestra aplicación, no es necesario
crear manualmente el usuario en el Servidor de Identidad. Simplemente cuando realizan el inicio de sesión
único (SSO) su cuenta es creada automáticamente, eliminando el tiempo y el esfuerzo asociados a la creación
de la cuenta. Este provisionamiento “Just-in-Time” trabaja con nuestro proveedor de identidad para pasar la
información correcta de usuario al IS.
- “Autenticadores Locales” (Local Authenticators): los autenticadores locales son procesos de autenticación
disponibles dentro del mismo Servidor de Identidad. El proceso de autenticación usuario/contraseña se lleva a
cabo enfrentando las credenciales introducidas contra los valores disponibles en el almacén de usuarios (user
store) conectado al servidor de Identidad.
- “Autenticadores Federados” (Federated Authenticators): los autentificadores federados son procesos de
autenticación que no se pueden llevar a cabo en el IS y que necesitan ser configurados para poder llegar a
aplicaciones externas, realizar el proceso de autenticación y enviar la respuesta de vuelta a nuestro IS.
- “Esquema/entorno de Provisionamiento” (Provisioning Framework): es el responsable de todos los
trabajos de provisionamiento realizados por el Servidor de Identidad. Este framework se integra con el Gestor
del Almacenamiento de Usuarios (User Store Manager) y recibe peticiones de provisionamiento desde el
framework de autenticación (Authentication Framework).
- “Gestor de Autorizaciones” (Authorization Manager): el Servidor de Identidad de WSO2 proporciona una
avanzada auditoría y gestión de derechos (ofrece mecanismos de gestión de derechos para cualquier llamada
REST o SOAP) además de un control de acceso basado en claims (a través de XACML, WS-Trust, OpenID,
etc.) y basado en roles (RBAC) mediante el uso de políticas (vía XACML).
El Servidor de Identidad también provee una interfaz de usuario amigable para la edición y gestión de
políticas, soporta múltiples PIPs y permite la distribución de políticas a varios PDPs. A su vez, también
proporciona un protocolo de red de alto rendimiento para la interacción PEP/PDP, para la evaluación de
políticas y para el almacenamiento de atributos en caché.
- “Configuraciónes del IdP and SP” (IdP and SP configurations): las configuraciones del proveedor de
identidades y del proveedor de servicios establecen las bases para todas las acciones que ocurren en los
framework de autenticación y provisionamiento.
- “Gestión del almacenamiento de usuarios” (User store manager): el IS de WSO2 puede implementar
distintos tipos de almacenamientos de usuario (user store) de forma flexible, véase mediante un LDAP
embebido, mediante un LDAP externo, mediante Microsoft Active Directory o mediante cualquier base de
datos JDBC (define una librería estándar para acceso a fuentes de datos, principalmente orientado a bases de
datos relacionales que usan SQL). Proporciona una API para integrar la gestión de identidades (de los
usuarios) con cualquier aplicación y permite a usuarios/organizaciones configurar su almacenamiento de
usuario a través de la consola de administración.
- “Gestor de atributos” (Claim manager): el IS permite gestionar fácilmente los claims (atributos) que
identifican a los sujetos dados de alta en el sistema. Un claim es un dato sobre un sujeto determinado, puede
ser cualquier atributo o características asociadas al sujeto, como su nombre, grupo al que pertenece,
preferencias, etc.
26
La identidad basada en claims es una forma común mediante la cual las aplicaciones pueden adquirir la
información de identidad de un sujeto, pero no sólo sirven para esto, ya que pueden ser usados también para la
propagación de identidades, empaquetando el claim en uno o más tokens13.
- XACML: este componente ya fue definido en el apartado de conceptos previos.
- “Auditoría” (Auditing): el Servidor de Identidad de WSO2 provee de una consola de administración o
gestión integral para temas de seguridad (a nivel empresarial) y cuenta también con una colección de
estadísticas internas estándar que nos permiten llevar una monitorización de nuestro sistema en todo momento.
- “Gestor de Identidades” (Identity manager): los sistemas TI/TIC de las empresas cambian constantemente
y sus políticas de acceso y seguridad con ellas. Esta necesidad de estar actualizadas se puede satisfacer
perfectamente gracias al gestor de identidad, que cumple todos los requisitos de seguridad. Además, cuenta
con una interfaz de usuario personalizable y fácilmente gestionable con el fin de garantizar la máxima
seguridad de cualquier sistema.
- “Provisionamiento de las entradas” (Inbound provisioning) y “Provisionamiento de salida” (Outbound
provisioning): estos componentes permiten al Servidor de Identidad enviar o recibir peticiones o solicitudes de
provisionamiento para determinados recursos o servicios.
Las peticiones de entrada de provisionamiento pueden ser SCIM o SOAP, mientras que las solicitudes de
provisionamiento puede enviarlas a las aplicaciones que soporten los siguientes conectores: SCIM, SPML,
Google y Salesforce. Estos conectores llegan a los proveedores de identidad que realizan el provisionamiento.
A continuación se presenta un esquema que resume las funcionalidades principales de las que hemos hablado.
Hasta aquí llega la introducción teórica al Servidor de Identidad de WSO2. En el apartado de desarrollo del
proyecto se realizará un análisis más exhaustivo acerca del funcionamiento práctico del componente y se
explicarán en detalle cuáles son las funcionalidades descritas anteriormente que se han usado para la
realización de este proyecto. Para más información acerca del IS, se puede consular tanto la documentación
proporcionada por WSO2 en su página oficial ([21] ) como a alguno de sus vídeos explicativos disponibles en
YouTube ([31] ).
13 Un token es una especie de mensaje (normalmente una cadena de caracteres) que posee un significado único dentro de un determinado entorno y que facilita el proceso de autenticación y/o autorización de una determinada entidad/sujeto.
Imagen 17. Funcionalidades del IS
27
3.2 Introducción al Application Server
El Servidor de Aplicaciones ([32] y [33] ) de WSO2 proporciona una solución completa para el alojamiento
(hosting), despliegue (inmediato) y gestión de aplicaciones y servicios web de forma fácil y segura. Se
encuentra en un nivel intermedio entre el back-end (lado del servidor; parte que procesa las entradas y
peticiones del front-end) y el front-end (lado del cliente; parte del software que interactúa con los usuario) de
un sistema y aúna las mejores características de las tecnologías de código abierto para aplicaciones web (Ej.
Apache Tomcat), servicios web (Ej. Apache Axis2) o servicios REST (Ej. JAX-RS) con las extensiones
WSO2 de gestión de código abierto, monitorización, clustering e inicio de sesión.
Al igual que el Identity Server (y toda la suite de productos WSO2) es 100% código abierto y está totalmente
desarrollado en base a la plataforma Carbon. Además, utiliza Apache Tomcat y es capaz de albergar cualquier
tipo de aplicación Web desplegable en Tomcat. Los usuarios pueden crear, gestionar y utilizar sus aplicaciones
y servicios de forma sencilla y unificada a través de la interfaz de usuario que ofrece el servidor de
aplicaciones.
El siguiente diagrama muestra cómo los consumidores (canales web y aplicaciones clientes) se conectan a una
aplicación desplegada en WSO2 AS:
Imagen 18. Esquema de funcionamiento del AS (I)
Otra de las funciones principales del AS es desplegar aplicaciones que están diseñadas para realizar ciertas
tareas, como la recuperación de datos desde una base de datos o la manipulación de los mismos. De esta
forma, los canales web externos se conectan a las aplicaciones web desplegadas en el AS para consumir los
servicios prestados por dichas aplicaciones. La aplicación desplegada en el AS define la ruta de acciones que
deben tomarse para servir el canal web (como la recuperación de datos desde la base de datos y su
presentación al usuario).
Imagen 19. Esquema de funcionamiento del AS (II)
28
29
DESARROLLO DEL PROYECTO
The Middleware Paradigm Shift that's Advancing the World.
- WSO2 -
31
a hemos hablado largo y tendido acerca de cuáles eran los objetivos del proyecto y de cuáles han sido
los conceptos o herramientas en los que nos hemos basado para desarrollar el proyecto. Ahora toca
abordar de forma exhaustiva y paso a paso cómo hemos desarrollado el proyecto, de forma que este
documento pueda ser tomado como punto de partida para crear cualquier tipo de sistema de control de acceso
personalizado y perfectamente funcional.
1 Instalación y análisis de las funcionalidades del Identity Server
Vamos a comenzar nuestra explicación con el segundo objetivo que se marcó en el proyecto, el de
“Instalación, configuración y puesta en funcionamiento del IS” (ya que se considera que la búsqueda y
recopilación de información no es necesario que sea detallado). Antes de comenzar con la explicación, decir
que toda la información acerca del proceso de instalación, arranque y configuración del IS se puede encontrar
en la la documentación oficial de WSO2 ([25] ), aquí sólo se realizará un resumen de los puntos
imprescindibles y que nos incumben en nuestro proyecto (comentando los puntos más problemáticos
encontrados y las soluciones aportadas para superarlos).
Lo primero que debemos hacer para poder empezar a trabajar con el IS es descargar el archivo (wso2is-
5.1.0.zip, que podemos encontrar en la referencia [26] ) disponible en la página de WSO2, en nuestro caso
hemos descargado la última versión disponible, la 5.1.0. Una vez descargado el archivo, debemos
descomprimirlo en la carpeta que deseemos, convirtiéndose ésta en nuestro directorio <IS_HOME> (del cual
haremos uso para referirnos a archivos y carpetas dentro del árbol de directorios del IS). En caso de disponer
de los archivos en el CD adjunto con esta memoria, dicho CD ejercerá como la carpeta donde hemos
descomprimido los dos componentes WSO2. Tras todo esto, sólo debemos ir al archivo llamado
wso2server.bat (localizado en la carpeta <IS_HOME>\wso2is-5.1.0\bin), ejecutarlo, esperar a que se arranque
correctamente el servicio y la interfaz web y acceder en nuestro navegador a la dirección
https://localhost:9443/carbon/admin/login.jsp (el puerto HTTPS que se usa por defecto para la interfaz de
administración es el 9443).
A continuación, y si todo ha ido correctamente, en nuestro navegador debe de aparecer una pantalla como la
que se muestra en la captura siguiente, que no es más que la ventana de inicio de sesión del IS. Podemos
acceder a la aplicación haciendo uso del usuario que está creado por defecto en el sistema, el usuario admin
con contraseña admin. Introducimos los dos valores en el formulario y pulsamos sobre el botón de iniciar
sesión.
Captura 1. Pantalla de inicio de sesión en la consola de gestión del IS
Una vez hemos iniciado sesión, se muestra el menú principal de la aplicación. En la zona izquierda de la
pantalla se muestra un índice con todas las herramientas disponibles en el IS y en la parte central se muestra
información genérica del servidor, del sistema operativo, de características java o de la BBDD.
En futuros desarrollos del proyecto si sería conveniente entrar de lleno en una configuración avanzada de cada
uno de los tributos (claims) que vayan a ser utilizados para adaptarnos de la mejor forma posible a la norma.
Una vez realizados los archivos LDIF correspondientes, sólo faltaría introducir la información que contienen
en el LDAP embebido del IS. Para ello, como ya comentamos anteriormente, haremos uso del software
Apache Directory Studio14 ([34] , [35] y [36] ), de ahora en adelante, ADS.
La apariencia inicial del software es la que se muestra en la siguiente captura (una vez ya se ha establecido la
conexión con el LDAP). En la zona izquierda de la pantalla podemos observar el árbol o estructura del LDAP,
en la que encontramos los usuarios y grupos que hay creados actualmente en el IS. En el centro de la pantalla
podemos observar los detalles del elemento que tenemos actualmente seleccionado (los objectClasses que
implementa, los atributos que tiene definidos y el valor que tiene asignado cada atributo). Básicamente, estas
serán las dos partes de la interfaz gráfica que nos interesarán y con las que trabajaremos.
Captura 31. Pantalla principal de Apache Directory Studio (I)
Antes de proceder con la inserción de archivos LDIF, vamos a explicar rápidamente cómo realizar la
configuración de la conexión del ADS con el LDAP del IS.
Primero hay que pulsar el botón de nueva
conexión en la ventana inferior izquierda de la
pantalla principal.
Una vez pulsado, hay que introducir los
parámetros de conexión correspondientes en las
distintas ventanas y pestañas que nos vayan
apareciendo. En la primera deberemos indicar
varios parámetros de red, como son el nombre de
la conexión que vamos a realizar, el nombre de
nuestro host y el puerto en el que arrancar el
servicio (por defecto para LDAP es el 10389,
pero se puede poner cualquiera entre 1 y 65535).
14 El Apache Directory Studio es una completa plataforma de herramientas de directorio pensada para ser usada con cualquier servidor LDAP, aunque está particularmente pensada para su uso con ApacheDS. Es una aplicación Eclipse RCP, compuesta por bastantes plugins (OSGi) que pueden ser fácilmente actualizados con otros adicionales.
Captura 32. Pantalla de configuración de la conexión al
LDAP
53
En la siguiente ventana de configuración que nos encontramos tenemos la definición de las características de
autenticación. En ella tenemos que indicar el método de autenticación que vamos a utilizar frente al servidor
LDAP (hasta el momento esta opción no es editable) y los parámetros de autenticación. El usuario que
utilizaremos para acceder al LDAP será el de Administrador del servidor (admin) cuya contraseña es “admin”.
Captura 33. Pantalla de configuración de la conexión LDAP (I)
Respecto al resto de ventanas de configuración que nos aparecerán, no es necesario modificar ningún valor de
las mismas, con los valores que vienen por defecto podemos realizar la conexión perfectamente con el LDAP
embebido al IS. Aun así, a continuación se muestran la configuración de las pantallas restantes para acabar de
mostrar el proceso de conexión al completo.
Una vez realizada toda la configuración correctamente, ya nos debería aparecer en la zona izquierda de la
pantalla principal (en la ventana LDAP Browser) el árbol de directorios correspondientes (tal y como se
aprecia en la Captura 31. Pantalla principal de Apache Directory Studio (I)). Ahora ya estaríamos conectados
a nuestro servidor LDAP y estaríamos en disposición de insertar los archivos LDIF que hemos creado para
poder utilizar los atributos que nos interesan (sacados del estándar correspondiente OASIS) a la hora de dar de
alta nuevas entidades (usuarios) en el IS.
Captura 34. Pantallas de configuración de la conexión LDAP (II)
54
El proceso de inserción se puede realizar en 5 sencillos pasos que van a ser detallados a continuación (partimos
de la base de que ya tenemos creados los archivos LDIF que queremos insertar, que tenemos instalado y
funcionando el IS y que tenemos el ADS arrancado y conectado al IS correctamente):
1. Lo primero que tenemos que hacer es localizar la ventana donde se muestra el árbol de directorios
(LDAP Browser), hacer click derecho sobre la entrada “ou=schema”, seleccionar “Import” y después
seleccionar “LDIF Import…”.
Captura 35. Pasos para importar un archivo LDIF
2. Tras el paso anterior, se nos abre una ventana emergente tal y como la que se muestra a continuación.
En ella simplemente tenemos que seleccionar el archivo LDIF que queremos insertar en el servidor
LDAP (mediante la pestaña LDIF File) y pulsar el botón “Finish”.
Captura 36. Pantalla de importación de archivos LDIF
55
Si no se muestra ningún tipo de error por pantalla significa que todo ha ido correctamente (el fichero
LDIF no presentaba problemas de estilo ni de configuración). En caso contrario, aparecerá una
ventana de error indicándonos cuál es el motivo por el cual no se ha podido realizar la inserción.
3. A continuación, tenemos que realizar una serie de actuaciones para que los cambios introducidos
entren en vigor en el IS. Para ello, lo primero que tenemos que hacer es cerrar el IS (parar el proceso
correspondiente) y después tenemos que editar los archivos de configuración “embedded-ldap.xml” y
“user-mgt.xml” (localizados en las rutas <IS_HOME>\wso2is-5.1.0\repository\conf\identity y
<IS_HOME>\wso2is-5.1.0\repository\conf respectivamente) para que en las propiedades
“AdminEntryObjectClass” y “UserEntryObjectClass” en vez de aparecer el nombre del archivo LDIF
establecido por defecto por WSO2 aparezca el nuestro propio que hemos creado e insertado
previamente en la estructura LDAP.
Captura 37. Cambio introducido en el archivo embedded-ldap.xml
Captura 38. Cambio introducido en el archivo user-mgt.xml
56
Una vez introducidos los cambios anteriores debidamente, hay que eliminar el directorio llamado
“root” (cuya ruta es <IS_HOME>\wso2is-5.1.0\repository\data\org.wso2.carbon.directory). De este
modo, tras el reinicio del IS, la partición por defecto de LDAP se creará de nuevo con la entrada del
usuario “admin” construida esta vez incluyendo el nuevo objectClass insertado.
4. Tras esto, arrancamos de nuevo el IS y el ADS, iniciamos sesión en el IS con las credenciales “User:
admin/Password: admin”, creamos un nuevo usuario en el sistema a través de la pestaña “Users and
Roles”, accedemos a la ventana “LDAP Browser” del Apache Directory Server, seleccionamos el
nuevo usuario insertado dentro de la entrada “ou=Users” y en la zona central de la pantalla (donde
aparecen los objectClasses y los atributos con los que ha sido construido el usuario) podemos apreciar
que aparecerá el objectClass que introdujimos a través de nuestro archivo LDIF correctamente.
En la captura anterior se puede observar el resultado final de la importación correcta del archivo LDIF
personalizado. Observamos que el objectClass “oasisPerson” que aparece en la captura lo definimos nosotros
mismos en el archivo LDIF que importamos correctamente y, además, en la parte de abajo podemos ver los
valores (de ejemplo) asignados a cada uno de los atributos (obligatorios y opcionales) asociados al usuario
“Kike”.
Una vez hecho esto, ya tendríamos solventada la parte de inserción de claims en el dialecto que utiliza por
defecto el IS de WSO2 (como ya se comentó, en vez de crear un dialecto nuevo que no podemos usar, se ha
modificado el que se utiliza por defecto) y el mapeo correcto con atributos válidos existentes en el LDAP
embebido.
De esta forma, ahora al entrar en la interfaz web del IS y acceder a la herramienta de gestión de roles y
usuarios, en la opción de editar la información de un usuario, nos aparecerían los claims (atributos) que hemos
añadido en el dialecto por defecto mediante los ficheros de configuración correspondientes (todos ellos
mapeados correctamente a través de los atributos existentes en LDAP).
Captura 39. Pantalla principal de Apache Directory Studio (II)
57
3 Creación y evaluación de políticas de control de acceso
En este apartado de la memoria vamos a entrar de lleno en el mundo de las políticas de control de acceso a
servicios o recursos dentro de un sistema. El objetivo principal de esta parte del proyecto va a ser la de crear y
probar un conjunto de políticas que basen su criterio de decisión en los atributos introducidos por nosotros
mismos en el dialecto por defecto del IS de WSO2 (recordemos, http://wso2.org/claims).
Para ello, vamos a hacer uso de dos herramientas, una interna del IS que ya se explicó en el apartado
correspondiente a la introducción del mismo (módulo PAP del IS) y otra herramienta externa ajena a WSO2
(SoapUI) que nos permite probar las distintas políticas existentes dentro del IS.
3.1 Uso de la herramienta PAP del IS para la creación y evaluación de políticas
Antes de proceder con las pruebas de funcionamiento del PAP, es necesario crear el set de políticas de ejemplo
que nos permitan demostrar que todas las actuaciones que se han ido explicando y realizando a lo largo del
proyecto han surtido efecto y son correctas.
A partir de la introducción que se hizo de la herramienta PAP del IS, se han creado dos políticas que nos
permiten comprobar la correcta configuración de los atributos basados en el estándar OASIS XSPA XACML
(la tercera política a la que no se hará alusión en este apartado será utilizada en el próximo).
Captura 40. Pantalla de administración de políticas
El contenido de “MiPrimeraPolítica” es el que se muestra a continuación.
En la captura se observa la estructura genérica de una política XACML normal y corriente, en la que hemos
marcado como objetivo (target) para la aplicación de la política el acceso al recurso “MiRecurso” y en la que
indicamos que sólo tienen permiso de lectura (read) a dicho recurso los usuarios cuya organización asignada
(organization) sea “ESI”.
Echemos la vista atrás y recordemos que este atributo “organización” del que estamos hablando no es más que
el correspondiente al claim que se introdujo en el dialecto por defecto de WSO2:
Captura 42. Ejemplo de atributo insertado en el dialecto por defecto del IS
Cuyo mapeo se realizó a través del archivo LDIF oasisPerson:
Captura 43. Parte del archivo LDIF creado para mapear los atributos insertados en el dialecto
Luego si ahora tuviéramos una serie de usuarios cualesquiera creados en el sistema (como los que se muestran
a continuación) deberían de poder tener acceso a dicho recurso (el IS debería devolvernos como respuesta a la
aplicación de la política un mensaje “Permit”) aquellos en cuyo campo “Oasis Organization” tuviera el valor
“ESI”.
Captura 44. Valor dado a los atributos de los usuarios creados en el IS
59
Ahora ya estamos en condiciones de comprobar que realmente el IS nos va a devolver el resultado “Pemit”
cuando intenten acceder al recurso los usuarios “Isabel” y “Kike” y el resultado “Deny” cuando el usuario que
intente acceder al recurso sea “admin”. Para ello, vamos a hacer uso de la opción “Try” que nos proporciona la
capacidad de probar cada política que creamos en el PAP.
Sólo debemos rellenar los campos necesarios para realizar la consulta con los valores adecuados:
Recurso (ficticio) al que queremos acceder: MiRecurso
Sujeto/Individuo que quiere acceder al recurso: Kike
Acción que se quiere realizar sobre el recurso: read
Nombre del entorno (opcional, ya que no lo contemplamos en ninguna de las reglas de nuestra
política): entorno
Captura 45. Prueba o testeo de la política “MiPrimeraPolitica”
Si ahora pulsamos sobre el botón “Test Evaluate”, obtenemos el resultado de realizar la petición con los datos
introducidos a la política:
Captura 46. Resultado de la evaluación de la política (I)
Si realizáramos el mismo procedimiento simplemente cambiando el valor del sujeto que desea acceder al
recurso por “Isabel”, obtendríamos el mismo resultado. En cambio, si pusiéramos como sujeto al usuario
“admin” obtendríamos una respuesta denegatoria como la que se muestra a continuación.
Captura 47. Resultado de la evaluación de la política (II)
60
Si queremos ver el código XACML que se intercambia en el proceso de petición-respuesta, en vez de pulsar el
botón “Test Evaluate” podemos pulsar sobre el botón “Create Request” para que se abra una nueva ventana en
la que se muestra la petición XACML que se va a realizar y posteriormente pulsamos sobre el botón “Test
Evaluate”.
Captura 48. Petición XACML para la política “MiPrimeraPolitica” (I)
En la captura mostrada a continuación se puede observar la respuesta proporcionada ante la petición
anteriormente realizada. En ella se muestra que el resultado de la decisión ha sido denegatorio (Deny) debido a
que al aplicar la política “MiPrimeraPolítica” sobre los datos proporcionados (entorno, admin, MiRecurso y
read) se ha comprobado internamente que el atributo “Oasis Organization” del usuario “admin” no tiene el
valor adecuado (tiene el valor “None”, cuando el valor necesario para poder acceder al recurso es “ESI”).
Captura 49. Resultado de la petición XACML realizada sobre la política “MiPrimeraPolitica” (I)
61
A continuación, y ya para acabar con esta primera política, podemos realizar el mismo procedimiento para
alguno de los usuarios que si cuentan con un valor adecuado del atributo “Oasis Organization”.
Captura 50. Petición XACML para la política “MiPrimeraPolitica” (II)
Captura 51. Resultado de la petición XACML realizada sobre la política “MiPrimeraPolitica” (II)
62
En cuanto al contenido de la segunda política (“MiSegundaPolítica”) que hemos creado como ejemplo para
seguir demostrando el funcionamiento de la configuración realizada, se muestra a continuación.
Captura 52. Código XACML de la política “MiSegundaPolitica”
En esta ocasión, la condición para que se aplique la política la hemos basado en el rol que tenga el usuario, de
esta forma, a todo usuario que tenga el rol “Medic” le será aplicada esta política cuando corresponda.Según la
configuración de usuarios que se mostró anteriormente, los usuarios que estarían afectado por esta nueva
política serían “Isabel” y “Kike”, ya que el usuario “admin” no cuenta con el rol “Medic” y no le sería
aplicable la política. De todas formas, vamos a proceder a probar dicha política con todos y cada uno de los
usuarios como se hizo anteriormente para comprobar que efectivamente funciona todo correctamente.
Captura 53. Pantalla de evaluación de la política “MiSegundaPolítica”
En este caso no vamos a asignar valor al valor correspondiente al entorno, para ver que, al igual que pasaba
con la política anterior, no afecta para nada en la respuesta que toma el IS al respecto (ya que en la política no
lo tenemos en cuenta, aunque podríamos perfectamente).
Antes de mostrar el resultado de la petición, analicemos los datos que se mandan en la consulta e intentemos
ver cuál será el resultado. Estamos diciendo que queremos acceder al recurso “MiRecurso” (en esta ocasión,
independientemente del recurso al que quisiéramos acceder la política se aplicaría igualmente), que el sujeto
que quiere acceder al mismo es “Kike” (tampoco es un valor que condicione la decisión de aplicación de la
política directamente, aunque si indirectamente) y que la acción que quiere realizar sobre el recurso es “write”
(una de las condiciones de la regla para permitir el acceso al usuario).
Hasta aquí todo bien, pero ahora el IS debe buscar la información adicional que le falta para, en primer lugar,
decidir si debe aplicar la política en este caso y, en segundo lugar, determinar la respuesta a devolver. Para
ello, primero comprueba cuál es el rol del usuario “Kike”, determinando que es “Medic” y que por lo tanto hay
que aplicarle la política, y después, comprueba cuál es el valor del “purposeOfUse”, que en este caso es
“Study” (realmente el valor de este atributo debería proporcionarse de forma dinámica dentro de la petición
XACML, de forma que no fuera un atributo de contexto fijo, sino que dependiera de cada petición realizada).
63
No debemos olvidar que, al igual que hicimos con la política anterior, nos estamos basando en un atributo que
hemos introducido nosotros mismos en el dialecto por defecto y en el servidor LDAP embebido en el IS.
Captura 54. Código necesario para introducir el atributo “purposeOsUse” en el dialecto por defecto
Dicho esto, procedemos a realizar las pruebas pertinentes con la política creada. En este caso se van a mostrar
directamente las peticiones XACML para que se aprecie claramente que el contenido de los mensajes
intercambiados es efectivamente el esperado.
Captura 55. Petición XACML para la política “MiSegundaPolitica” (I)
Se comprueba que, como esperábamos, la decisión de la petición es positiva (“Permit”).
Captura 56. Resultado de la petición XACML realizada sobre la política “MiSegundaPolitica” (I)
64
Probando ahora con exactamente los mismos valores de los atributos pero cambiando el usuario que realiza la
petición tendremos lo siguiente.
Captura 57. Petición XACML para la política “MiSegundaPolitica” (II)
En este caso la decisión que toma el sistema (realmente, el PDP interno del IS) es la de denegar el permiso de
acceso al recurso porque, en este caso, el usuario “Isabel” tiene un valor distinto al que indica la regla para el
atributo “purposeofuse” (tiene el valor “Teach” en vez de “Study”). Luego podemos confirmar que la política
cumple su función a la perfección.
Antes de seguir avanzando, vamos a recalcar de nuevo el hecho de que las pruebas que se están realizando, las
políticas que se están utilizando y los atributos a partir de los cuales estamos tomando las decisiones de
autorización no tendrían por qué usarse del mismo modo en un escenario de prueba real. De hecho, que el
valor que toma el atributo “pruposeofuse” sea fijo (parámetro de contexto) no tiene sentido fuera de nuestra
prueba, ya que realmente debería venir dado dentro de la petición XACML (ser un parámetro dinámico).
Captura 58. Resultado de la petición XACML realizada sobre la política “MiSegundaPolitica” (II)
Antes de acabar con esta herramienta que nos proporciona el IS para probar el funcionamiento de las políticas
que creamos, vamos a mostrar un ejemplo del último resultado que nos podría devolver el sistema, que sería
cuando la política no es aplicable según los valores que se mandan en la petición. En el caso de esta última
política, podríamos poner un ejemplo de esto usando el usuario “admin”, ya que no le sería aplicable la política
debido a que no cuenta con el rol “Medic”.
65
Vamos a mostrar lo anteriormente comentado mediante un par de capturas para demostrar que efectivamente
cuando lo probamos sucede lo que esperamos.
Captura 59. Petición XACML para la política “MiSegundaPolitica” (III)
Captura 60. Resultado de la petición XACML realizada sobre la política “MiSegundaPolitica” (III)
3.2 Uso de SoapUI para la evaluación de políticas
En este subapartado del proyecto vamos a hacer uso de una herramienta muy útil y ampliamente utilizada en el
ámbito de las aplicaciones y servicios web (que utilizan SOAP como protocolo de comunicación) llamada
SoapUI ([37] y [38] ).
Ya se realizó una introducción del protocolo SOAP en el apartado Conceptos previos de esta memoria, pero no
se nombró nada de esta herramienta, así que vamos a hacer una breve descripción de la misma para entender
cómo vamos a utilizarla para evaluar las políticas creadas en el IS.
SoapUI (Soap User Interfaz) es un software multiplataforma de código libre y gratuito que proporciona una
solución sencilla para realizar pruebas de testeo de servicios web. Además, posee una interfaz gráfica fácil de
usar que permite crear y ejecutar todo tipo de pruebas automatizadas (funcionales, de regresión, de
cumplimiento y de carga, etc.) en un entorno de prueba único (proporciona una cobertura de pruebas completa
y es compatible con todos los protocolos estándar existentes).
66
Realizada ya la presentación de esta herramienta, vamos a explicar para qué la hemos utilizado en nuestro
proyecto y por qué sería muy útil considerarla o utilizarla en futuras mejoras o ampliaciones del proyecto.
El Servidor de Identidad de WSO2, como todos los módulos de la suite de productos que ofrece, cuenta con un
amplio conjunto de APIs15 que nos permiten utilizar muchas de las funcionalidades del IS de forma sencilla a
través del uso de peticiones SOAP incluidas en mensajes HTTP. De esta forma, podemos utilizar, por ejemplo,
las APIs relacionadas con la gestión y aplicación de políticas (para realizar peticiones de acceso a recursos o
servicios) o las relacionadas con la gestión de usuarios (para pedir los roles actualmente existentes en el
sistema).
SoapUI nos permite probar el funcionamiento de dichas APIs de forma rápida y sencilla de forma que, antes
de usarlas en cualquier tipo de sistema o software externo, podamos saber cómo funcionan, qué parámetros de
entrada necesitan, qué valores devuelven y en general cómo se comportan.
Antes de seguir avanzando, debemos introducir un elemento importante para la utilización de cualquiera de las
APIs que ofrece el IS de cara al exterior, el término WSDL (Web Services Description Language). Éste no es
más que un formato XML que se utiliza para describir servicios Web (describe la interfaz abstracta a través de
la cual un cliente puede acceder al servicio y a los detalles de cómo se debe utilizar). Así, WSDL se usa a
menudo en combinación con SOAP (que es quien realiza las llamadas a las funciones listadas en el WSDL) y
con XML Schema (que establece la estructura del archivo WSDL).
Aclarados ya todos los conceptos previos fundamentales, podemos procededer con la explicación del
procedimiento a seguir para poder hacer uso de los distintos servicios web ofrecidos por el IS en SoapUI.
Los servicios web que proporcionan los productos WSO2 son conocidos como servicios de administración
(admin services) y son accesibles a través de rutas de acceso (URLs) como la mostrada a continuación:
https://localhost:9443/services/UserAdmin?wsdl.
Hay que destacar que, según la configuración por defecto, los usuarios del IS no pueden ver los WSDL de los
servicios de administración por cuestiones de seguridad. Para habilitar dichos servicios y poder invocarlos es
necesario establecer el valor del elemento “<HideAdminServiceWSDLs>” del archivo de configuración
“<IS_HOME>/repository/conf/carbon.xml” a “false”.
Una vez hecho esto, y habiendo reiniciando posteriormente el servidor IS, ya tendríamos acceso a todos los
WSDL disponibles. A continuación se muestra el resultado de acceder al WSDL indicado anteriormente a
través de un navegador cualquiera.
Captura 61. Ejemplo de archivo “wsdl” del IS mostrado en un navegador web
15 Una API (Application Programming Interface) es un conjunto de reglas (código) y especificaciones que las aplicaciones pueden usar para comunicarse entre ellas (igual que la interfaz de usuario facilita la interacción humano-software, las APIs facilitan la interacción software-software). Dicho de otra forma, permiten hacer uso de funciones ya existentes en otro software (o de la infraestructura ya existente en otras plataformas) reutilizando así código que se sabe que está probado y que funciona correctamente.
67
Aunque podemos encontrar en la documentación proporcionada por WSO2 el listado completo de los
servicios SOAP expuestos por el IS buscando en la documentación proporcionada en la página web
(https://docs.wso2.com/display/IS510/Permissions+Required+to+Invoke+Admin+Services), si lo deseamos,
también podemos listarlos a través del terminal de Windows (o del S.O correspondiente). Simplemente hay
que arrancar el servidor añadiendo la opción “- DosgiConsole” (<IS_Home>/bin/wso2server.bat -
DosgiConsole).
Una vez arrancado el servidor correctamente, si pulsamos el botón “enter” en la consola o terminal que ya
tenemos abierto, veremos que aparece en pantalla la sentencia “osgi>”, que nos permite navegar a través de las
funcionalidades del IS en modo consola. En nuestro caso, sólo nos interesará utilizar el comando
“listAdminServices”, que nos devolverá un listado de todos los servicios desplegados y activos en el IS (para
obtener más información acerca de las posibilidades que ofrece esta opción de arrancado del servidor, utilizar
el comando “help”).
Captura 62. Listado de servicios web ofrecidos por el IS
Ahora que ya conocemos el listado de servicios ofrecidos por el IS (con su correspondiente ruta de acceso al
WSDL) y tenemos todo configurado debidamente, ya podríamos hacer uso de cualquiera de ellos (en este caso
utilizaremos SoapUI para verificarlos y probarlos). Para ello sólo tenemos que descargarnos el programa
(disponible en el siguiente enlace https://www.soapui.org/), arrancarlo, en la pantalla principal pulsar sobre el
icono “SOAP” y en la ventana que se abre a continuación indicar el nombre que queramos dar al nuevo
proyecto SOAP que vamos a crear y la URL que identifica al WSDL del servicio que queremos usar. A
continuación se presenta una captura de pantalla en la que se muestra la apariencia inicial de SoapUI con la
ventana emergente que aparece cuando pulsamos el icono “SOAP” situado en la barra de herramientas de la
Captura 63. Ventana de configuración de un nuevo servicio en SoapUI
Una vez hecho esto, pulsamos sobre el botón de “OK” y automáticamente en el menú desplegable de la zona
izquierda de la pantalla podemos observar cómo se nos crea una entrada para el nuevo proyecto que hemos
introducido. Si desplegamos dicha carpeta o entrada, observamos dos Endpoints16 distintos mediante los cuales
podemos acceder a los métodos del servicio, y si abrimos cualquiera de ellos, encontramos los métodos
disponibles en los mismos. Para utilizarlos, sólo debemos desplegar de nuevo el método que deseemos y hacer
doble clic sobre la petición (Request) para que se abra una ventana con apariencia de navegador web (en la
parte superior de la pantalla se muestra la dirección a la que enviaríamos el mensaje) en la que se muestra el
contenido SOAP de la petición que se realizaría al servicio web.
No debemos olvidar que estamos utilizando servicios web de administración, luego el IS nos exige que nos
autentiquemos antes de poder usarlos. Esto se consigue accediendo al menú de autenticación (Auth) situado en
la parte inferior de la pantalla, seleccionando como tipo de autorización “Básica” (Basic) e introduciendo
como usuario y contraseña los correspondientes al administrador del IS (admin, admin). Este procedimiento
habría que repetirlo para cada método que queramos utilizar.
Captura 64. Configuración de la autencicación necesaria para el uso de servicios en SoapUI
16 Un endpoint indica una localización específica para acceder a un servicio web usando un protocolo y formato de datos específico (resumidamente, es una entidad o recurso referenciable a la que se pueden enviar mensajes).
69
Cuando ya tenemos todo configurado correctamente, debemos introducir los valores adecuados en los campos
de la petición SOAP que vamos a enviar al servidor y pulsar sobre el icono de la flecha verde situada en la
esquina superior izquierda para realizar la petición. En la captura mostrada a continuación se aprecia un
ejemplo de la ventana que se abre cuando queremos realizar una petición a un servicio web.
Captura 65. Ejemplo de uso de un determinado servicio en SoapUI (I)
Tras realizar la petición, en la pantalla se mostraría el contenido de la petición SOAP que hemos realizado en
la parte izquierda (ya estaba de antes) y la respuesta SOAP que nos ha devuelto el servicio web en la parte
derecha. En función de los parámetros que hayamos introducido y del método que hayamos utilizado el
servicio nos devolverá un resultado u otro.
A continuación se muestra un ejemplo en el que usamos el método “getRoleNames” del servicio
“RemoteUserStoreManager” para recuperar los roles actualmente existentes en el IS. Se puede apreciar
perfectamente como el servicio web, al mandarle la petición “getRoleNames” nos devuelve un listado de
elementos de tipo “<ns:return>” con los roles correspondientes.
Captura 66. Ejemplo de uso de un determinado servicio en SoapUI (II)
70
De la misma forma que en el ejemplo anterior se pedía al IS los roles existentes en el sistema, podemos pedirle
que evalúe las políticas que deseemos en función de una serie de parámetros que le indicamos en la petición
SOAP (que es lo que realmente íbamos buscando con la explicación de esta herramienta).
De este modo, si hacemos uso del método “getDecisionByAttributes” del servicio web “Entitlement” podemos
realizar una evaluación de las políticas que estén actualmente publicadas en el PDP del IS (recordemos, en el
subapartado anterior sólo nos centramos en probar las dos políticas de ejemplo que creamos en el PAP, pero
para hacerlas accesibles y evaluables desde el exterior, es necesario publicarlas en el PDP mediante la opción
“Publish To My PDP” existente en cada política creada del PAP).
Dicho esto, si publicamos la política “MiSegundaPolitica” (por ejemplo) en el PDP del IS y realizamos la
petición SOAP mostrada a continuación, indicándole los atributos correspondientes (sujeto que quiere acceder
al recurso, recurso al que se quiere acceder y acción que se quiere realizar sobre el recurso), los resultados que
deberíamos obtener son los mismos que obtuvimos en el subapartado anterior (con la herramienta “Try”).
Captura 67. Uso del servicio “EntitlementService” para probar la política “MiSegundaPolitica” (I)
Captura 68. Uso del servicio “EntitlementService” para probar la política “MiSegundaPolitica” (II)
71
Captura 69. Uso del servicio “EntitlementService” para probar la política “MiSegundaPolitica” (III)
Captura 70. Uso del servicio “EntitlementService” para probar la política “MiSegundaPolitica” (IV)
En todas las capturas que se han mostrado anteriormente se observa claramente que las respuestas que
obtenemos tras realizar las peticiones al servicio web son las mismas que las que obtuvimos en el apartado Uso
de la herramienta PAP del IS para la creación y evaluación de políticas (kike permit, Isabel Deny y
Admin NotApplicable).
Aquí finaliza el apartado correspondiente a la creación y evaluación de políticas de control de acceso. En él
hemos visto dos opciones distintas perfectamente válidas para probar o testear el funcionamiento de las
políticas que creemos en nuestro IS. Adicionalmente, con este apartado se ha corroborado que efectivamente
todos los cambios que se han introducido dentro del dialecto por defecto de WSO2 funcionan correctamente y
que, en principio, el IS es una herramienta perfectamente válida para actuar como sistema de control de acceso
a recursos, ofreciendo un set completo de servicios web de los que podemos hacer uso a través de una
aplicación externa o a través de otro módulo de la suite que ofrece WSO2.
72
4 Instalación y análisis de las funcionalidades básicas del Application Server
De la misma forma que hicimos con el IS, vamos a proceder a explicar rápidamente cómo descargar e instalar
el AS en nuestro sistema (necesario para montar el escenario de prueba). Antes de comenzar, destacar que toda
la información acerca del proceso de instalación, arranque y configuración del AS se puede encontrar en la
documentación oficial de WSO2 ([33] 92), aquí sólo se realizará un resumen de los puntos imprescindibles y
que nos incumben en nuestro proyecto.
También hay que mencionar que realmente, gracias a la modularidad de WSO2, no sería necesario volver a
descargar e instalar todo el conjunto de componentes al completo necesarios para desplegar el AS en una
máquina, ya que, al basarse en el componente Carbon (como toda la suite de productos WSO2), simplemente
podríamos descargar desde la sección “Configure” del IS los módulos necesarios para poder hacer uso de las
funcionalidades del AS que nos interesaran (sólo necesitamos indicar un repositorio y descargar los módulos
que deseemos).
Imagen 20. Esquema de funcionamiento del repositorio de WSO2
Sin embargo, y para no tener que entrar en temas de integración y configuración de módulos, en nuestro caso
optaremos por realizar la instalación completa de nuevo en nuestro equipo (que sería lo que realmente
tendríamos que hacer si tuviéramos un sistema SOA con los componentes repartidos por distintos equipos o
entornos).
A continuación se muestra la pantalla donde podemos descargar los módulos a través de repositorios de
WSO2 dentro del IS (que se pueden encontrar a su vez en la página oficial de WSO2) de forma fácil y sencilla.
Captura 71. Pantalla de instalación de funcionalidades y características adicionales (módulos)
73
Lo primero que debemos hacer para poder empezar a trabajar con el AS es descargarnos el archivo disponible
en la página de WSO2, en nuestro caso nos hemos descargado la última versión disponible, la versión 5.3.0.
Una vez descargado el archivo, debemos descomprimirlo en la carpeta que deseemos, convirtiéndose ésta en
nuestro directorio <AS_HOME> (del cual haremos uso para referirnos a archivos y carpetas dentro del árbol
de directorios del AS). Tras todo esto, sólo debemos ir al archivo llamado wso2server.bat (localizado en la
carpeta <AS_HOME>\wso2as-5.3.0\bin), ejecutarlo, esperar a que se arranque correctamente el servicio y
acceder en nuestro navegador a la dirección https://localhost:9444/carbon/admin/login.jsp (recordemos que el
puerto que usa por defecto Carbon es el 9443 (para la consola de gestión), pero como queremos tratar los dos
componentes de forma completamente independiente y utilizarlos a la vez, debemos modificar el puerto por
defecto de la segunda consola de gestión que utilizará el AS.
Este cambio debemos realizarlo en el fichero de configuración de Carbon (carbon.xml) contenido en la ruta
<AS_HOME>\wso2as-5.3.0\repository\conf, del AS. Simplemente debemos establecer el offset que queramos
para sumar dicho valor al del puerto por defecto, de forma que, por ejemplo, si ponemos 1 de offset, 9443 +1 =
9444 = Nuevo puerto de despliegue del servicio.
Captura 72. Valor del atributo “offset” del archivo “Carbon.xml” del AS
Una vez hecho lo indicado anteriormente, y si todo ha ido correctamente, en nuestro navegador debe aparecer
una pantalla similar a la que se mostraba con el IS. Dicha pantalla es la consola de gestión del AS. Podemos
acceder a la aplicación haciendo uso del usuario que está creado por defecto en el sistema, el usuario admin
con contraseña admin. Introducimos los dos valores en el formulario y pulsamos sobre el botón de iniciar
sesión.
Captura 73. Pantalla de inicio de sesión del WSO2 Application Server
Una vez hemos iniciado sesión, se muestra el menú principal de la aplicación. En la zona izquierda de la
pantalla se muestra un índice con todas las herramientas disponibles en el AS y en la parte central se muestra
información genérica del servidor, del sistema operativo, de características del java VM o de la BD.
En nuestro caso, de todas las herramientas que podemos encontrar en la zona izquierda de la pantalla, las que
nos interesarán son las relacionadas con las aplicaciones (Applications) en la pestaña Main.
En principio, el resto de pestañas por las que se puede navegar (Monitor, Configure y Tools) o el resto de
herramientas disponibles (Services, Carbon Applications y Modules) no serán foco de nuestro estudio, aunque
se recomienda encarecidamente que se consulten las distintas posibilidades que ofrecen, ya que lo estudiado
en este proyecto es una pequeña parte de todas las características y funcionalidades de las que dispone el AS.
Captura 74. Pantalla de incio del AS
Si accedemos a la opción list de la herramienta Applications podemos observar una pantalla como la mostrada
a continuación. En ella se muestra una tabla con información asociada a las aplicaciones que hay actualmente
desplegadas sobre el AS. Podemos ver desde los tipos de las aplicaciones (Web, Jaggery17 o JAX-WS/RS)
hasta el número de sesiones que hay activas para cada aplicación, pasando por el estado o la fecha de última
modificación.
Captura 75. Pantalla con el listado de aplicaciones corriendo actualmente en el AS
17 Jaggery es un lenguaje o esquema para desarrollar aplicaciones web y servicios web basados en HTTP que contempla todos los aspectos de la aplicación: front-end, comunicación, lógica del lado del servidor y persistencia en Javascript. Uno de los propósitos de este framework es reducir la diferencia de escritura entre las aplicaciones web y los servicios web. En definitiva, Jaggery combina todas las ventajas de Javascript con la flexibilidad y la libertad en el desarrollo y en las etapas de implementación.
75
Adicionalmente, encontramos varias opciones interesantes para cada una de las entradas de la tabla de
aplicaciones desplegadas en el AS, como son la de “Go To URL”, para acceder directamente a la aplicación a
través de una pestaña del navegador, la de “Download”, para descargar en un archivo comprimido .zip la
estructura de carpetas de la aplicación o las de “Context”, con las que accedemos a una nueva ventana donde
se muestra información detallada y específica de la aplicación que hemos seleccionado.
Captura 76. Información y estadísticas de una determinada aplicación web del AS
Una vez explicados todos los conceptos necesarios, ya estamos en disposición de montar nuestra propia
aplicación web en el AS. Para ello simplemente tenemos que crear la estructura de directorios y los archivos
habituales necesarios para desplegar una aplicación web sobre Tomcat (para más información acerca de la
aplicación web creada, consultar el apartado Archivos y recursos de la Aplicación Web Genérica del capítulo
de anexos). Una vez creada, sólo tenemos que agruparla dentro de una carpeta con el nombre que queramos e
insertarla en la ruta <AS_HOME>\wso2as-5.3.0\repository\deployment\server\webapps. Una vez hecho esto,
debemos reiniciar el servidor, acceder a la ventana mostrada en la Captura 75. Pantalla con el listado de
aplicaciones corriendo actualmente en el AS y utilizar la opción “Go To URL” para probar el funcionamiento
de la aplicación.
A continuación se muestra el resultado de seleccionar la opción anterior en el navegador.
Captura 77. Aplicación Web de prueba desplegada en el AS
76
5 Creación del escenario de prueba
5.1 Introducción
Como ya hemos comentado en varias ocasiones en esta memoria, XACML es un lenguaje de políticas basado
en un esquema XML que nos permite gestionar la autorización de las peticiones de acceso a recursos o
servicios. Para determinar el resultado de dichas autorizaciones, obtenemos un conjunto de atributos (claims)
de la petición y los enfrentamos a una serie de políticas XACML existentes. En nuestro caso, el elemento al
que vamos a intentar acceder es un determinado recurso web (protected.jsp) contenido dentro de una
aplicación web genérica. Para poder acceder a este recurso, tanto los atributos contenidos en la petición
realizada como las características del sujeto que desea acceder al recurso deberán cumplir las restricciones que
marcan las políticas XACML correspondientes.
Imagen 21. Motor de evaluación de políticas XACML
Estas políticas XACML estarán alojadas en un PAP y serán usadas por un PDP (la gestión de las
autorizaciones en función de estas políticas se llevarán a cabo dentro del mismo PAP). Como ya sabemos, el
punto donde se toman este tipo de decisiones de autorización se denomina Punto de Decisión de Políticas
(PDP) y, nuestro proyecto, dicha funcionalidad se realizará dentro del IS. Recordemos que para tener acceso a
las políticas publicadas en el PDP del IS tenemos que hacer uso del servicio web llamado “EntitlementService”
(visto en el apartado Uso de SoapUI para la evaluación de políticas).
Ahora bien, a la hora de gestionar las autorizaciones, también es necesario que exista un punto en el que las
solicitudes o peticiones de acceso sean interceptadas, controladas y manejadas convenientemente. Recordar de
nuevo que este punto se denomina Punto de Ejecución de Política (PEP). En el escenario de prueba que vamos
a montar, utilizaremos un servlet (contenido dentro de la aplicación web que estará almacenada y desplegada
dentro del AS) como filtro de las peticiones de acceso entrantes, ejerciendo por lo tanto de PEP del sistema.
En los siguientes subapartados se van a describir los pasos que se han seguido para montar un escenario de
prueba local en el que un sujeto determinado desea acceder a un cierto recurso web protegido (protected.jsp).
Como ya se ha mencionado anteriormente, esto se realizará haciendo uso de los componentes WSO2 IS (que
actuará como PDP, PAP y PIP) y AS (que albergará la aplicación web con el correspondiente servlet que
ejercerá de PEP). Por último, decir que aunque lo que realmente nos interesa es el proceso de autorización de
acceso al recurso correspondiente mediante el IS, previamente llevaremos a cabo la autenticación de los
sujetos a través del AS.
77
5.2 Esquema del escenario de prueba
Imagen 22. Esquema funcional del escenario de prueba realizado
En la imagen anterior podemos observar todos los elementos que componen el escenario de prueba que se ha
montado y como se relacionan en el proceso de control de acceso a un determinado recurso. Tal y como se
indicaba en el subapartado anterior, tenemos por un lado el IS, que ejerce de PDP (es el que gestiona la
autorización al recurso) y por otro lado el AS, que contiene una aplicación web dentro de la cual se definen las
características de un servlet que ejerce de PEP ante las peticiones de acceso al recurso protegido
(protected.jsp). Dicho servlet estará recogido dentro del archivo “web.xml” ([39] ), contenido dentro de la
carpeta “WEB-INF” de la aplicación web que estará alojada a su vez dentro del AS (consultar Imagen 25.
Estructura de directorios de la aplicación web creada para más información).
En cuanto a la función del componente “Entitlement PEP Proxy”, únicamente comentar que ejerce de proxy18
de comunicación entre el PDP (IS) y el PEP (servlet) y que su funcionamiento no es relevante dentro de lo que
nos interesa en este proyecto. Lo único que hay que entender bien es que tenemos un servlet que ejerce de
filtro para las peticiones de acceso a un recurso protegido y que éste inicializa una especie de “PEP proxy”
para comunicarse con el IS y poder obtener el resultado de las autorizaciones correspondientes.
A continuación se muestra un pequeño esquema donde se muestra la estructura y localización de los elementos
o componentes principales de los que vamos a hacer uso en nuestro escenario de prueba:
18 Un proxy es un representante o sustituto autorizado para actuar en nombre de otra entidad/máquina y ejercer de intermediario en sus transacciones.
Servidor de Aplicaciones
(AS)
Aplicación Web
Servlet de filtro de
autorizaciones
Servidor de Identidades
(IS)
Políticas de acceso
Autorización
PDP PEP
E
PAP
Equipo local (PC)
Funcionalidades definidas
en el archivo “web.xml”
Imagen 23. Esquema conceptual del escenario de prueba montado
PIP
78
A continuación se muestra la distribución de los elementos de nuestro escenario de prueba dentro del esquema
de la norma genérica correspondiente al control de acceso a recursos. Hay que destacar que, aunque en este
proyecto no se haga uso de todos los elementos que estarían recogidos dentro del IS, en desarrollos futuros del
mismo sería posible (y recomendable) dar cabida al resto de componentes que aporten información relevante
para el control de acceso a recursos o servicios.
Imagen 24. Relación del sistema de control de acceso con los componentes WSO2 IS y AS.
5.3 Configuración del escenario de prueba
Para empezar a hablar de la configuración que permite poner en práctica el escenario de prueba, vamos a partir
de la base de que ya tenemos instalados y configurados correctamente tanto el IS (ver apartado Instalación y
análisis de las funcionalidades del Identity Server) como el AS (ver apartado Instalación y análisis de las
funcionalidades básicas del Application Server).
También hay que mencionar que todo el procedimiento que se explica en este subapartado ha sido extraído de
varios recursos web, cuyo pilar principal se centra en un tutorial oficial de WSO2 ([40] , [41] , [42] , [43] y
[44] ). A partir de ellos se ha realizado una síntesis de los puntos necesarios para desplegar el escenario de
prueba y se han elaborado todos los archivos o elementos necesarios (básicamente, una política de acceso y
una aplicación web) para poder probar el funcionamiento del sistema.
Dicho esto, se pasa a explicar el procedimiento. Lo primero es crear en el IS una política de control de acceso
que se adecue a nuestro objetivo de proteger el recurso web de nuestra aplicación. Para ello, haremos uso de la
metodología explicada en el apartado Uso de la herramienta PAP del IS para la creación y evaluación de
políticas e insertaremos una política que base su decisión de autorización en alguno de los claims o atributos
(introducidos en el dialecto por defecto del IS que configuramos según nuestros intereses en el apartado
Creación de un dialecto siguiendo la norma XSPA XACML de OASIS) asociados al sujeto que está intentando
acceder al recurso.
En nuestro caso, hemos decidido basar la decisión de autorización en función del atributo “purposeOfUse” (en
que su valor sea o no “Study”, igual que hicimos en el apartado Uso de la herramienta PAP del IS para la
creación y evaluación de políticas con la política “MiSegundaPolítica”) cuando se intenta realizar un “GET”
del recurso “protected.jsp”. De esta forma, y considerando siempre tanto el criterio de decisión de autorización
como la política creada en sí misma como meros ejemplos para demostrar el funcionamiento del sistema, a
continuación se muestra una captura de pantalla de la estructura final que presentaría la política XACML.
WSO2 AS
79
Captura 78. Código XACML de la política “Entitlement_Filter_Sample_Policy”
A partir del archivo XML, podríamos importar directamente la política en el IS (mediante las opciones Add
New Entitlement Policy, Import Existing Policy) y publicarla en la herramienta PDP (recordemos, mediante el
uso de la opción Publish To My PDP) fácilmente. Una vez publicada, ya podríamos acceder a ella a través del
servicio correspondiente que ofrece el IS de cara el exterior (EntitlementService).
En este punto ya tendríamos configurada la parte del IS, ahora sólo quedaría gestionar la parte del AS.
Como ya se explicó en apartados anteriores de esta memoria, el AS lo vamos a utilizar para desplegar una
determinada aplicación web que queremos proteger. Para ello, y antes que nada, lo que debemos hacer es crear
y configurar dicha aplicación debidamente para que se comporte como queremos (hay que indicar que se ha
utilizado la misma aplicación web que viene recogida en el tutorial mencionado con anterioridad como guía
para desarrollar la nuestra propia).
La aplicación web se localizará en la ruta <AS_HOME>\wso2as-5.3.0\repository\deployment\server\webapps
de la estructura de directorios de AS (en ella insertaremos todas las carpetas y archivos necesarios para que la
aplicación funciona correctamente) y constará básicamente de 4 archivos:
index.jsp: recurso al que accedemos automáticamente cuando entramos en la aplicación web.
Cualquier sujeto tiene acceso a este recurso.
protected.jsp: recurso protegido al que vamos a intentar acceder. Recurso al que somos redirigidos
cuando el resultado de la autorización ha sido positivo. Sólo aquellos sujetos cuyos atributos y
características cumplan las condiciones y políticas recogidas en el PDP podrán acceder a este recurso.
error.jsp: recurso al que somos redirigidos cuando el resultado de la autorización de acceso al recurso
“protected.jsp” es negativo.
web.xml: archivo de configuración almacenado en la carpeta “WEB-INF” que proporciona
información de configuración y despliegue de los componentes web que componen nuestra aplicación
web. Nuestro objetivo es configurar este archivo para que actúe de PEP, utilizando la característica
que poseen los servlets como filtro para gestionar las autorizaciones de las peticiones entrantes y
poder proporcionar una decisión basada en políticas o reglas XACML.
80
A continuación se muestra la estructura de directorios y archivos que componen la aplicación web desplegada
dentro del AS.
Ahora bien, ¿por qué hemos decidido utilizar un servlet como filtro para proporcionar la autorización a un
recurso? Básicamente, porque cualquier desarrollador de aplicaciones web es perfectamente capaz de definir
un filtro dentro de un servlet en una aplicación web java. Incluso podemos usar dicho filtro en cualquier tipo
de “contenedor” de aplicaciones web (no sólo el AS de WSO2 nos permite hacer esto).
También, hay que hacer hincapié en que éste servlet hará uso de un proxy (lo inicializará él mismo) para
comunicarse con el IS y que dicho proxy será el responsable de llevar a cabo el proceso de autorización
(comunicará el PEP con el PDP):
Primero, hará uso del servicio de autenticación del IS (AuthenticationAdmin Service) para iniciar
sesión en él con el rol “Admin” (administrador del sistema).
Tras esto, el “PEP Proxy” habrá iniciado sesión como administrador y ya podrá hacer uso del servicio
de autorizaciones (“Entitlement Service”) para evaluar las peticiones XACML entrantes al recurso
protegido.
A continuación, el “PEP Proxy” obtendrá los parámetros (atributos) necesarios para evaluar la
petición frente a las políticas XACML contenidas en el IS (aquellas que no se proporcionen en la
misma petición las podrá buscar el IS internamente) y realizará la llamada correspondiente al IS.
Por último, recibirá la decisión de autorización y se la proporcionará al PEP que redirigirá al sujeto
hasta el recurso adecuado.
Como ya hemos comentado anteriormente, todo esto se configurará adecuadamente en el archivo web.xml.
Debido a la moderada extensión que pueden llegar a presentar cada uno de los recursos que hay que configurar
en la aplicación web y a que su visualización no resulta crítica para entender el funcionamiento del escenario
de prueba, se insta al lector a que acuda al apartado de anexos Archivos y recursos de la Aplicación Web del
escenario de prueba para consultar el código al completo o directamente al enlace del tutorial que se ha
seguido y que ya se proporcionó al inicio de este subapartado.
Por último, y ya para acabar con este apartado, decir que una vez introducida y configurada debidamente la
aplicación web en la ruta indicada, al arrancar el AS y acceder a la lista de aplicaciones, ya nos saldría nuestra
aplicación desplegada y perfectamente accesible.
Captura 79. Listado de aplicaciones web desplegadas en el AS (después de incluir las dos nuevas)
Imagen 25. Estructura de directorios de la aplicación web creada
81
5.4 Test de funcionamiento del escenario de prueba
Por último, y para acabar ya con el apartado correspondiente a la creación y configuración del escenario de
prueba montado, se va a proceder a mostrar el funcionamiento final del sistema.
Para probarlo, tenemos que arrancar tanto el IS como el AS y acceder a nuestra aplicación web a través de un
navegador web cualquiera. Podemos obtener la dirección (URL) donde está accesible nuestra aplicación
entrando en la opción “List” del apartado “Applications” del AS, buscando nuestra aplicación en la lista de
“Running Applications” y pinchando sobre la acción “Go to URL”.
Captura 80. Listado de las aplicaciones web desplegadas en el AS
Cuando pinchamos sobre la acción “Go To URL” accedemos por defecto automáticamente al recurso
“index.jsp” de nuestra aplicación web (desplegada dentro del AS).
Captura 81. Página de inicio de la aplicación web (index.jsp) creada para el escenario de prueba (I)
82
El elemento más importante de la página web que se muestra es el botón de acceso (Access), cuya función es
demandar al usuario que se identifique frente a la aplicación (pidiendo usuario y contraseña) y realizar un GET
del recurso protected.jsp (recordar que la autenticación de los usuarios se realiza en el AS, no en el IS). Esta
funcionalidad de identificación se ha definido y configurado dentro del archivo web.xml de nuestra aplicación,
donde ya dijimos que también se establecían las características del servlet que ejerce de PEP en nuestro
sistema. En este punto, y hasta que no se realice correctamente la autenticación, no entrarán en juego ninguno
de los puntos del sistema de control de acceso (PEP, PDP, PAP o PIP).
Captura 82. Página de inicio de la aplicación web (index.jsp) creada para el escenario de prueba (II)
Hay que destacar que, como se ha decidido instalar y configurar ambos softwares (IS y AS) de forma
desacoplada (en vez de instalar el componente Carbon e ir añadiendo las funcionalidades que nos interesaran)
en el mismo equipo local, la autenticación de los usuarios se realiza por defecto en el AS (no se ha
externalizado al IS), por lo que es necesario que los mismos usuarios que existen en IS existan en el AS (ya
que no comparten el mismo directorio). A continuación se muestran un par de capturas donde se explica cómo
podemos crear los usuarios en el AS de forma rápida y sencilla (de forma parecida a como se hacía en el IS).
Recurso “index.jsp”
De esta forma, si tenemos creados los usuarios correctamente en ambos componentes (en nuestro caso,
tenemos creados en ambos los usuarios kike, Isabel y admin) ya podemos realizar una prueba válida mediante
nuestra aplicación web.
Captura 84. Apartado de usuarios y roles
dentro del AS Captura 83. Opción de añadir nuevo usuario en el AS
83
Lo único que tenemos que hacer es pinchar sobre el botón “Access”, introducir usuario y contraseña con los
que queramos realizar la prueba y pinchar sobre el botón “Iniciar sesión” de la ventana emergente. Como ya se
ha comentado antes, este proceso de autenticación se está realizando en el AS y es anterior a la realización de
la petición de acceso al recurso compartido (si esta autenticación resulta fallida, no se continúa con el proceso
de autorización).
Captura 85. Pantalla emergente de identificación de usuario de la aplicación web (index.jsp)
Recordemos que, en el subapartado anterior, definimos que la política que establecía la condición para la
decisión de autorización se iba a basar en que el atributo “purposeOfUse” del sujeto en cuestión tomara o no el
valor “Study”. Recordemos también que los valores que tienen asignados los tres usuarios creados en el
sistema para dicho atributo son: None (para admin), Teach (para Isabel) y Study (para kike).
Luego según lo comentado anteriormente, y si toda la configuración que hemos realizado es correcta,
únicamente el usuario kike debería poder acceder al recurso protegido “protected.jsp”. Si introducimos su
nombre de usuario y contraseña debidamente y pulsamos el botón “Iniciar Sesión” observamos que
efectivamente la aplicación web nos redirige hasta la página que deseábamos. Se acaba de realizar el proceso
de autorización de forma satisfactoria (el resultado de la decisión del IS ha sido “Accept”).
Captura 86. Pantalla de acceso permitido al recurso protegido (protected.jsp)
84
Si por el contrario, los datos que introducimos son los de alguno de los otros dos usuarios, la aplicación web
nos redirige al recurso “error.jsp” para indicarnos que no tenemos permiso para acceder al recurso protegido
“protected.jsp”. En este caso, el resultado del proceso de autorización por parte del IS es “Deny” (Consultar la
Captura 89. Diagrama de secuencias del funcionamiento de la aplicación web para ver cómo interactúan los
distintos componentes del escenario en el proceso de autenticación).
Captura 87. Pantalla de acceso prohibido al recurso protegido (error.jsp)
Por último, a continuación se indica el caso de pulsar el botón “Cancelar” o el icono en forma de cruz de la
ventana emergente que aparece cuando tenemos que autenticarnos. La aplicación web (Tomcat) nos devuelve
automáticamente una pantalla genérica de error indicándonos que es necesario una autenticación vía HTTP.
Captura 88. Pantalla de error de autenticación obligatoria
Queda demostrado por lo tanto que el escenario de prueba que se ha montado funciona perfectamente en base
a la política creada (que volvemos a repetir, es una cualquiera tomada como ejemplo) y a la configuración que
se realizó del IS para adaptarlo al estándar OASIS correspondiente (edición del dialecto por defecto).
Se puede consultar el proceso de interacción que realizarían los distintos elementos del sistema de control
(PEP, PDP, PAP y PIP) recogidos dentro del IS y del AS en la Imagen 24. Relación del sistema de control de
acceso con los componentes WSO2 IS y AS.
85
A continuación, y ya para acabar de explicar en profundidad el funcionamiento del escenario de prueba e
identificar claramente los componentes que están interactuando y los mensajes que se están interacambiando
entre ellos se presenta el siguiente diagrama de interacción.
Captura 89. Diagrama de secuencias del funcionamiento de la aplicación web
Con esta captura finalizamos el apartado de creación del escenario de prueba local. Recordar de nuevo que
para más información al respecto, se puede consultar el recurso web que se ha tomado como referencia para
realizar todo el montaje y configuración del escenario (recogido en el correspondiente apartado de
Bibliografía).
86
87
CONCLUSIONES
efinitivamente, podemos concluir que hemos llegado a la desembocadura de este trabajo. En este
apartado de resultados y conclusiones se van a comentar y analizar todos y cada uno de los frutos que
se han obtenido de su realización, incluyendo tanto los que se han obtenido directamente como los que
se hayan podido encontrar tras el amplio proceso de investigación y documentación del mismo.
A su vez, se va a exponer un abanico de futuras mejoras que podrían llevarse a cabo para aumentar las
prestaciones y el rendimiento del sistema montado y se van a indicar aquellos objetivos y tareas que se han
quedado en el tintero ya sea por falta de tiempo.
1 Resultados
Entrando ya en materia, de lo primero que vamos a hablar es de los resultados que hemos obtenido de la
realización del proyecto en general y del escenario de prueba en particular. Podemos asegurar sin miedo a
equivocarnos que los resultados obtenidos han sido los esperados (coherentes y correctos) y que realmente se
han conseguido modificar las características adecuadas del IS para adaptarlo parcialmente al estándar XSPA
de OASIS y conseguir mostrar su utilidad en un entorno de prueba local como sistema de control de acceso a
recursos (con ayuda del AS).
Mediante el uso de los componentes IS y AS de WSO2 hemos conseguido implementar un sistema de control
de acceso útil y gratuito en un entorno de prueba controlado (local) perfectamente funcional que corrobora el
correcto funcionamiento de las políticas creadas y del dialecto configurado. Esto es precisamente lo que
íbamos buscando con la realización de este proyecto, sentar las bases para la creación y configuración de un
sistema de control de acceso normalizado (mediante el uso de XACML), basado en componentes open source
y siguiendo las indicaciones de un estándar internacional (aunque en nuestro caso dicho estándar esté se centre
en el ámbito médico, a partir de las indicaciones dadas en esta memoria el sistema de control de acceso se
podría adaptar a cualquier norma o estándar que quisiéramos). Gracias a esto, con la implementación de un
único producto conseguiríamos abarcar una gran cantidad de posibilidades, entornos y oportunidades de
negocio.
Otro hecho importante que hay que recalcar dentro de este proyecto es su aplicación y utilidad en la vida real
(en un entorno empresarial real), ya que el sistema de control de acceso que se ha creado (recordemos, de
forma local) sería perfectamente aplicable (reutilizable) dentro de cualquier entorno o institución sanitaria
tanto pública como privada (hospitales, clínicas, centros de salud, etc.), altamente escalable y fácilmente
configurable (recordemos que la arquitectura WSO2 incluye un conjunto de componentes que podemos
interconectar de la forma que queramos en función de nuestros objetivos e intereses). Por ello, podemos decir
que desde un punto de vista económico y a largo plazo, las expectativas del sistema no podrían ser mejores.
También hay que destacar que, aunque el balance del desarrollo del proyecto es bastante positivo, existen un
par de factores que hacen que el sistema desarrollado no esté completo al 100% y que pudiera dar más de sí.
Tanto en el apartado correspondiente al set de políticas creado y usado como en el apartado de configuración
del IS en función del estándar OASIS no hemos conseguido alcanzar el nivel de detalle deseado, ya que, por
ejemplo, en el caso de las políticas, no se ha llegado a crear un set de políticas publicadas lo suficientemente
complejo y completo como para poder aplicarlo directamente en un ámbito profesional real, sólo hemos
introducido el concepto de política y hemos probado su funcionamiento con ejemplos sencillos. En el caso de
la configuración del IS, ya comentamos en el apartado correspondiente que en el proceso de autorización sólo
se ha conseguido que intervengan las características y atributos del sujeto que desea tener acceso al recurso,
pero no se ha logrado hacer que las características o atributos del recurso al que se desea acceder o del entorno
en el que nos movemos también intervinieran en el proceso (más allá de las posibilidades que nos ofrecen los
propios atributos que ya vienen predefinidos en el IS por defecto).
Dejando ahora de lado el ámbito técnico de nuestro proyecto, a continuación se va a proceder a identificar las
conclusiones y apreciaciones sacadas acerca de la suite de productos que ofrece WSO2 como empresa.
D
88
Una de las cosas más importantes y a tener en cuenta dentro de este proyecto es el hecho de que hemos
trabajado únicamente con softwares de código abierto (open source), es decir, totalmente gratuitos, y que esta
característica no ha representado ninguna merma de las prestaciones ni funcionalidades de los elementos
utilizados. Pero no sólo los dos productos que hemos usado de WSO2 son de código libre, toda la suite de
productos que ofrece es totalmente gratuita y el único servicio por el que podríamos llegar a pagar si
quisiéramos es por el de soporte, mantenimiento y gestión de las aplicaciones que montáramos a partir de
softwares de WSO2.
Aun así, es cierto que en función de cual sea nuestro objetivo o finalidad al usar los componentes en cuestión,
el proceso de gestión, adaptación e integración de los distintos softwares en nuestro sistema puede llegar a
presentar un alto grado de dificultad para usuarios no expertos (llegando a suponer un grado de implicación o
dedicación variable en función de los conocimientos técnicos de los que disponga el usuario administrador).
También hay que aclarar que, aunque es relativamente sencillo encontrar información y recursos de soporte o
ayuda de calidad sobre la gama de productos de WSO2 (principalmente a través de su página web y foro
oficiales), prácticamente toda esta información la vamos a encontrar en inglés y localizada en un único punto,
lo que supone un inconveniente a la hora de la contrastación y verificación de la información recabada.
Pero todo esto no desmerece el hecho de que WSO2 sea, actualmente, la empresa basada en el uso de
aplicaciones software SOA número uno del mundo, ofreciendo una amplia gama de productos en distintos
campos tecnológicos (Analytics, Identity Management and Security, Mobile and IoT, Services and App Dev,
etc.) totalmente open source y fáciles de utilizar. Además, como ya se comentó anteriormente, también ofrece
un servicio de gestión y soporte de sus componentes que nos permitiría adaptar a nuestro gusto cualquiera de
sus productos en nuestro negocio o entorno empresarial. También organiza regularmente eventos y cursos
formativos por los distintos países del mundo de donde dispone de una sede física para informar y formar a las
personas interesadas en el uso de sus softwares.
A continuación se muestra una imagen en la que se observan todas las sedes oficiales que tiene repartidas
WSO2 por el mundo.
Imagen 26. Mapa-mundi de WSO2
89
Como resumen a todas las conclusiones y resultados, podemos concluir que los objetivos que se marcaron al
principio de este trabajo se han cumplido con un alto nivel de efectividad (en términos generales) ya que, sin
llegar a entrar en gran nivel de detalle en ciertos aspectos, se ha conseguido realizar una guía actualizada y útil
de las pautas a seguir para poder montar un sistema de control de acceso a recursos totalmente funcional de
forma local y adaptado a un determinado estándar OASIS utilizando componentes proporcionados por WSO2
y diversos conocimientos y tecnologías de distinta índole (SOAP, LDAP, XML, XACML, Lenguajes de
programación Web, etc.).
Por último, y ya para acabar de hablar de WSO2 como empresa, recalcar que, de cara a desarrollar futuros
proyectos tecnológicos, es actualmente una de las mejores opciones que podemos encontrar dentro del
mercado de soluciones SOA, ofreciendo una gran previsión de futuro y presentando un número de usuarios y
una cuota de mercado en ascenso desde el año 2005 (sus desarrollos son usados actualmente en empresas de
renombre tanto a nivel nacional como internacional, como por ejemplo Ebay, Everis, West Interactive o
Trimble). Por todo esto, y por todos los conocimientos y conceptos que he adquirido durante la realización de
esta memoria, recomendaría totalmente considerar la solución que propone WSO2 con sus distintos
componentes en cualquier desarrollo o proyecto software SOA dentro cualquier ámbito tecnológico actual.
Imagen 28. Diagrama de uso de los productos de WSO2
Imagen 27. Campos tecnológicos a los que se dedica WSO2
90
2 Líneas futuras
Hablando ahora de las posibles mejoras que podríamos llevar a cabo en el proyecto, hay que hacer especial
hincapié en el hecho de que, aunque el trabajo ha sido ejecutado en un solo equipo (PC), realmente el sistema
que se ha montado (y por lo tanto, los componentes que se han utilizado) estaría diseñado para su uso en un
entorno que siga el paradigma (SOA). De esta forma, una futura línea de desarrollo sería el de probar el
sistema creado en un escenario en el que los componentes usados estuvieran instalados en varios equipos,
teniendo un sistema distribuido como tal (e incluso sería interesante añadir algún componente o módulo más
para seguir introduciendo funcionalidades más avanzadas en el sistema).
También tenemos hablar de un par de factores (que ya se comentaron en el subapartado anterior) que se
podrían mejorar y hacer que el sistema desarrollado aumentara su rendimiento y utilidad de cara a un escenario
empresarial real. Estamos hablando de los apartados correspondientes al set de políticas creado y usado dentro
del PDP y al de configuración del IS en función del estándar OASIS.
En el caso de las políticas creadas, probadas y usadas en el IS, se puede llegar a crear un conjunto de políticas
bastante más complejo que hiciera que el sistema de control de acceso, y por lo tanto el funcionamiento del
PDP (proceso de autorización), se asemejara bastante más a una situación real. En el caso de la configuración
del IS en función del estándar OASIS, se podría dar cabida al uso de más elementos de información (mejorar
las funcionalidades relacionadas con el uso de PIPs o el uso de distintos directorios/bases de datos) a la hora de
tomar decisiones de autorización (no sólo información del sujeto, sino también del recurso al que se quiere
acceder o del entorno en el que se produce el acceso) para hacer que el sistema ofreciera un rango más amplio
de posibilidades de acceso y de configuración de políticas.
A su vez, otro de los temas que podríamos y deberíamos mejorar en futuros desarrollos del proyecto sería la
adaptación fiel al estándar OASIS tomado como modelo de referencia, ya que para que el sistema que
montáramos fuera práctico, versátil y útil (de cara a usarlo genéricamente en cualquier entorno sanitario que se
nos ocurriera), tendría que cumplir todas y cada una de las restricciones e indicaciones que marca la norma (en
nuestro caso, hemos simplificado todos los atributos suponiendo que son de tipo string y no hemos puesto
restricciones a los posibles valores que pueden tomar).
Ya para acabar de comentar las apreciaciones de mejoras técnicas que se pueden hacer del trabajo realizado,
vamos a hablar acerca de los componentes WSO2 usados y de los módulos que los componen. Y es que en el
escenario de prueba que se ha montado, hemos instalado y utilizado el IS y AS por separado (en el mismo
equipo), repitiendo la instalación de módulos y funcionalidades comunes que ambos comparten. Debido a
esto, y al hecho de que el escenario montado ha sido local (todo en el mismo equipo), la posible mejora a
realizar sería la de probar a instalar el middlweware Carbon (que es el núcleo principal de WSO2) e irle
añadiendo las funcionalidades y módulos necesarios para añadir las características del IS y del AS al mismo
(resumidamente, utilizar los módulos de WSO2 como pequeños puzzles que podemos encajar a nuestro antojo
en función del sistema, arquitectura o funcionalidades que queramos implementar). De esta forma, no
instalaríamos por duplicado módulos comunes, ahorraríamos espacio de almacenamiento y mejoraríamos el
rendimiento del sistema.
3 Alegato final
Aquí ponemos punto y final a la sucesión de capítulos que detallan el proceso de realización del proyecto.
Con él, se ha dado el primer paso en la personalización de WSO2 IS al dominio sanitario y se ha conseguido
realizar una plataforma que facilitará al Grupo de Ingeniería Biomédica el desarrollo de prototipos para la
validación de sus resultados de investigación (una de las motivaciones principales de nuestro proyecto).
Espero que este documento sirva, en última instancia, para mejorar la calidad de vida de las personas en
general y de los profesionales sanitarios en particular.