proyecto fin de gradobibing.us.es/proyectos/abreproy/90865/descargar... · proyecto fin de grado...
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
2.1 XACML Y SAML 8 2.1 SOAP 10 2.2 LDAP 13 2.3 Estándares OASIS 18
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
Conclusiones 87 1 Resultados 87 2 Líneas futuras 90 3 Alegato final 90
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.
4
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
(namespaces3) que son usados en el mensaje.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
</SOAP-ENV:Envelope>
Tabla 1. Envoltorio de un mensaje SOAP
2.1.3.2 SOAP Header
La cabecera o header es una sección opcional. Es un mecanismo genérico para extender las características de
los mensajes SOAP de una manera descentralizada y sin un acuerdo previo entre las partes que se comunican.
En caso de estar presente debe ser el primer hijo de la sección envelope.
A modo de ejemplo, algunas de las extensiones que pueden ser implementadas mediante esta construcción son
transportar información auxiliar para la autenticación, manejo de transacciones, etc.
<SOAP-ENV:Header>
<User Information>
</SOAP-ENV:Header>
<SOAP-ENV:Header>
<Transaction Information>
</SOAP-ENV:Header>
Tabla 2. Cabecera de un mensaje SOAP
2.1.3.3 SOAP Body
La sección cuerpo o body actúa como contenedor de la información que se envía al receptor del mensaje,
debiendo de estar siempre presente en los mensajes SOAP. Debe estar ubicado a continuación de la cabecera,
si está presente, o ser el primer hijo de envoltorio si no lo está.
El uso típico de esta sección es proveer un mecanismo simple de intercambiar información con el receptor del
mensaje SOAP. En esta parte del mensaje es donde se localizan las invocaciones RPC o los resultados de la
invocación.
3 Los namespaces se utilizan para garantizar la unicidad de los elementos SOAP y evitar posibles ambigüedades dentro del mensaje.
12
<SOAP-ENV:Body>
<m1:RemoteMethodName xmlns:m1="some URI">
<arg1>value1</arg1>
<arg2>value2</arg2>
</m1:RemoteMethodName>
<m2:RemoteMethodName xmlns:m2="some URI">
<arg1>value1</arg1>
</m2:RemoteMethodName>
</SOAP-ENV:Body>
Tabla 3. Cuerpo de un mensaje SOAP
2.1.4 Ejemplo de mensaje SOAP
A continuación se muestra un ejemplo de una solicitud SOAP GetLastTradePrice realizada al servicio
StockQuote. La petición SOAP incluye un parámetro de tipo cadena (string) y la respuesta SOAP devuelve un
valor de tipo flotante (float). Antes del ejemplo, recordar de nuevo el concepto de espacios de nombres
(namespaces) XML, utilizados para eliminar las posibles ambigüedades que pueda darse entre los
identificadores de SOAP y los identificadores específicos de la aplicación y recordar también que las reglas
que rigen el formato de la carga útil XML en SOAP son totalmente independientes las reglas que controlan la
carga útil transportada por HTTP.
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Ejemplo 1. Mensaje SOAP embebido en una petición HTTP
A continuación se muestra el mensaje de respuesta, que no es más que un mensaje HTTP con la información
SOAP correspondiente como carga útil (payload):
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
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:
DN: cn=Robert Smith, ou=people, dc=example, dc=com
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.
19
3 Introducción a los componentes de WSO2
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.
Y
32
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 identidades (Identity) y las relacionadas con las políticas o
derechos (Entitlement, que son totalmente específicas del servidor de identidad).
En principio, el resto de pestañas por las que se puede navegar (Monitor, Configure y Tools) o el resto de
herramientas (Manage o Registry) no serán foco de nuestro estudio, aunque se recomienda encarecidamente
que se consulten las distintas posibilidades que ofrecen los distintos módulos, ya que lo estudiado en este
proyecto es una pequeña parte de todas las funcionalidades de las que dispone el IS.
Captura 2. Menú principal del IS
Pero todavía podemos acotar más aún las herramientas de las que vamos a hacer uso en este proyecto, ya que,
aunque de la pestaña Entitlement vamos a usar las dos herramientas disponibles (PAP y PDP), de la pestaña
Idendity sólo vamos a hacer uso de las herramientas User and Roles, User Stores y Claims.
Una vez localizadas las herramientas que vamos a utilizar en estre proyecto, podemos proceder con el detalle
de las mismas (breve introducción y forma de uso).
Con respecto a las herramientas PAP y PDP, como ya se explicó su función en el apartado XACML Y SAML,
dentro de Conceptos previos, vamos a proceder directamente con la explicación de cómo utilizarlas en el IS.
En cuanto al PAP, es la herramienta que debemos usar para administrar las políticas (expresadas en XACML)
existentes en el sistema. Podemos crear, borrar, editar e incluso probar las políticas que creamos de forma
local. Para añadir una nueva política en el sistema, sólo tenemos que acceder a la opción Policy Administration
y pinchar sobre el botón verde de la parte superior de la pantalla (Add New Entitlement Policy).
Con respecto a la otra opción que se nos ofrece (Policy Publish), simplemente mencionar que presenta
opciones de configuración relacionadas con la publicación de políticas. Podemos utilizar la configuración que
presenta por defecto, ya que es perfectamente válida para desarrollar nuestro proyecto y no es necesario
modificar nada en este aspecto.
33
Captura 3. Pantalla de Administración de Políticas del IS
Una vez hemos accedido al menú de creación de nuevas políticas, se muestra la pantalla recogida en la
siguiente captura. En ella se nos muestran varias posibilidades a la hora de crear políticas XACML, ya sea
crearlas mediante una interfaz visual amigable, importarlas directamente desde un archivo XML o redactarlas
directamente mediante el uso de un editor de texto XML incluido en el sistema.
En nuestro caso, se harán uso de las opciones Simple Policy Editor (útil para crear políticas simples de forma
rápida y sencilla, pero inservible para futuras pruebas mas complejas, ya que la interfaz gráfica mostrada por
defecto sólo muestra una serie de opciones estándar), Import Existing Policy (para importar directamente
políticas XACML previamente creadas) y Write Policy in XML (para crear políticas mediante código XML).
Captura 4. Pantalla de adición de nuevas políticas
A continuación se puede visualizar la pantalla que se muestra cuando accedemos a la primera de las opciones
de inserción de políticas (Simple Policy Editor). Se puede observar que, rellenando unos cuantos campos
bastante intuitivos, se puede crear una política perfectamente válida de forma muy sencilla y sin tener que
manejar en ningún caso código XML.
34
Captura 5. Pantalla de creación de políticas XACML
Una vez finalizada la política, ésta se añadiría a la lista de políticas disponibles de la pantalla “Policy
Administration” y podríamos proceder a probarla. Para probar el funcionamiento de cualquiera de las políticas
creadas el IS proporciona una opción (Try), en cada una de ellas, con la que accedemos a un menú genérico en
el que podemos introducir una serie parámetros por defecto para probar la política.
Captura 6. Pantalla de prueba de políticas
De forma adicional, el IS permite realizar peticiones escribiendo el código XACML directamente mediante un
editor de texto propio (esto será lo que nosotros utilizaremos para realizar pruebas de políticas complejas que
no se basan únicamente en los parámetros que nos ofrece el IS por defecto).
Una vez introducidos los datos o realizada la petición XACML directamente en el editor de texto, podemos
evaluar la política pulsando el botón “Test Evaluate” y el IS nos devolverá una de las siguientes respuestas:
Permit: cumplimos las restricciones/condiciones de la política.
Deny: no cumplimos las restricciones/condiciones de la política.
Not Applicable: significa que la política no es aplicable.
35
Captura 7. Pantalla de evalución de políticas (código de la petición XACML)
Cabe mencionarse que, en el momento de la aplicación o ejecución de políticas, el IS hace uso tanto de los
datos proporcionados en la petición XACML como de los datos que tiene almacenados internamente en el
sistema (LDAP embebido), por lo que evalúa tanto parámetros externos dados como parámetros almacenados
internamente para tomar la decisión final.
Una vez hemos probado el funcionamiento de nuestra política podría interesarnos publicarla de cara al exterior
(para que fuera accesible por entidades ajenas al IS) mediante la herramienta PDP del IS. Para publicar una
política, debemos acceder a la pantalla “Policy Administration” y hacer uso de la opción “Publish To My
PDP” existente para cada política (consultar Captura 3. Pantalla de Administración de Políticas del IS). Una
vez pulsada dicha opción, sólo tendríamos que configurar las opciones que quisiéramos en la pantalla de
publicación de políticas “Publish Policy” que se abre automáticamente y pulsar el botón “Publish”.
Captura 8. Pantalla de publicación de políticas
Una vez hecho esto, si accedemos a la pestaña “Policy View” de la herramienta PDP, podemos observar la
política que hemos añadido (“externalizado”). En esta interfaz se nos da la posibilidad de seleccionar el
algoritmo de ejecución que queremos que se aplique a nuestro set de políticas, la posibilidad de activar o
desactivar políticas concretas, la posibilidad de eliminarlas o la posibilidad de editar su orden (en función del
orden de las políticas y del algoritmo de ejecución seleccionado el resultado de la decisión que devuelva el
PDP podrá ser uno u otro).
36
Captura 9. Pantalla de visualización de políticas
Hasta aquí la explicación de las herramientas y funcionalidades básicas del apartado “Entitlement” que
utilizaremos en nuestro proyecto. Vamos a continuar explicando el otro apartado que ya comentamos que
necesitábamos para desarrollar el sistema de control de acceso, el apartado “Identity”.
Dentro de este apartado, dijimos que las herramientas principales en las que nos íbamos a centrar eran la de
“Users and Roles”, la de “User Stores” y la de “Claims”.
Abordando ya la primera de las herramientas (“Users and Roles”), la ventana que nos aparece cuando
pinchamos sobre la opción “List” es la que se muestra a continuación. En ella tenemos la posibilidad de listar
los usuarios o roles existentes actualmente en el sistema (pulsando “Users” o “Roles”) y la opción de
modificar la contraseña del usuario con el que hemos entrado en el IS.
Captura 10. Pantalla de gestión de usuarios y roles
Tanto si pulsamos en el icono de “Users” como en el de “Roles”, se nos muestra una ventana en la que se nos
listan los usuarios/roles creados actualmente (por defecto, sólo está creado el usuario admin con el rol admin,
aunque en la captura mostrada a continuación se pueden observar un par de usuarios creados a posteriori) y en
la que podemos configurar una serie de características de los elementos representados.
37
Captura 11. Pantalla de gestión de usuarios
En la ventana de usuarios, las dos opciones que nos importan realmente son la de asignar roles (“Assign
Roles”) y la de editar el perfil del usuario (“User Profile”). La primera de ellas es muy importante, ya que todo
usuario debe de tener obligatoriamente, y como mínimo, un rol asignado y, dependiendo de este rol, tendrá
unos privilegios u otros dentro del sistema (podrá usar unas herramientas u otras dentro del IS) y de cara al
exterior.
Captura 12. Pantalla de asignación de roles a un usuario
La otra opción que hemos identificado como importante es la de configurar la información del perfil del
usuario (“User Profile”). Dentro de esta pestaña podemos dar valor a los atributos (claims) que definen y
caracterizan a un usuario (y lo diferencia del resto). Como se explicará en apartados posteriores, estos atributos
se pueden modificar para hacer que los parámetros que definen o identifican a un usuario en nuestro sistema
sean los que nosotros queramos (en nuestro caso, serán atributos relacionados con el ámbito de la salud). En la
captura mostrada a continuación se muestran los parámetros que se han configurado en este trabajo (como se
verá más adelante) en vez de los parámetros que vienen configurados por defecto en el IS.
38
Captura 13. Pantalla de configuración de los atributos de un usuario
Hay que destacar también que dichos atributos (en el ámbito del IS llamados claims) serán necesarios y
relevantes dentro de la ejecución del políticas, ya que, tal y como hemos indicado en páginas anteriores, el
PDP, a la hora de tomar una decisión ante una petición XACML, hace uso tanto de los parámetros o atributos
contenidos en la propia petición como de los almacenados localmente en el IS (claims a los que nosotros
hemos asignado un valor en esta pantalla de gestión de usuarios).
Captura 14. Pantalla de gestión de roles
Con respecto a la ventana de roles (mostrada en la captura anterior), y sin llegar a entrar demasiado en detalle
ya que no será una parte crítica en nuestro proyecto, comentar simplemente que en ella se pueden gestionar
distintas opciones relacionadas con las características de los roles creados en el sistema (desde cambiar el
nombre del rol o modificar los permisos que tiene en el sistema hasta asignar usuarios al rol o eliminar dicho
rol).
39
Finalizada ya la explicación de las funcionalidades de las que vamos a hacer uso dentro de la funcionalidad
“Users and Roles”, avanzamos hacia la siguiente de las opciones, el almacenamiento de usuarios (User
Stores). En esta herramienta se nos ofrece la posibilidad de crear un nuevo “almacén de usuarios” a nuestro
gusto, pudiendo configurar todas las opciones que se nos muestran en la Captura 16. Pantalla de creación de
un nuevo “almacenamiento” de usuarios.
En un principio se consideró la creación de un nuevo “User Store” para poder dar cabida a las nuevas
características que se querían introducir en el IS, ya que el almacenamiento que el sistema trae por defecto sólo
permite la inclusión de información relacionada con usuarios (personas) y no la de otro tipo de entidades,
como serían recursos o entornos, pero tras analizar detenidamente el procedimiento a seguir y las acciones que
hay que realizar para su creación y configuración, se determinó que era bastante más sencillo modificar o
introducir los cambios necesarios en el “almacén de usuarios” que trae el IS por defecto en vez de crear uno
nuevo. En las siguientes capturas se muestran las pantallas de administración de almacenamientos de usuarios.
Captura 15. Pantalla de gestión de los “almacenamientos” de usuarios
Captura 16. Pantalla de creación de un nuevo “almacenamiento” de usuarios
Según lo comentado en el último párrafo, finalmente las funcionalidades de esta herramienta no han sido
utilizadas para implementar la nueva configuración que se pretendía llevar a cabo, aunque sería una de las
posibilidades que nos ofrece WSO2 para llevar a cabo modificaciones o adaptaciones como la que estamos
realizando en este proyecto.
Por último, comentar rápidamente que esta herramienta también es interesante a la hora implementar
modificaciones en el proceso de autenticación de usuarios (a nosotros lo que nos interesa es el proceso de
autorización que ofrece el IS, aunque ambos van generalmente de la mano).
40
Por último, y ya para finalizar este apartado de opciones y funcionalidades de las que vamos a hacer uso dentro
del IS, procedemos a abordar la opción “Claims”.
Como ya hemos mencionado alguna vez, cuando dentro del IS hablamos de claims a lo que realmente nos
estamos refiriendo es a los atributos que caracterizan las entidades que definimos en el sistema (por defecto,
usuarios).
En la captura mostrada a continuación, observamos que tenemos dos opciones distintas dentro de ésta
herramienta. La primera que nos encontramos, con el nombre de “Add”, nos permite añadir un nuevo claim a
un dialecto (conjunto de claims) ya existente o crear un nuevo dialecto en el sistema.
Captura 17. Pantalla de gestión de dialectos y atributos (claims)
Con respecto a la posibilidad de añadir un nuevo dialecto al sistema, fue la medida que inicialmente se
consideró y realizó para poder dar cabida a la nueva configuración de atributos o claims en función del
estándar OASIS que se habían establecido como punto de referencia, pero tras implementar dicho dialecto, se
descubrió que en la versión actual del IS no es posible cambiar el dialecto que se utiliza por defecto como
referencia para la presentación y gestión de atributos de los usuarios (nuevos y existentes) del sistema.
A continuación se muestran las pantallas mediante las cuales se puede crear un nuevo dialecto o se puede
añadir un nuevo claim a un dialecto ya existente en el IS.
Captura 18. Pantalla de creación de nuevo dialecto
41
Captura 19. Pantalla de creación de un nuevo atributo (en un dialecto)
Por lo tanto, se decidió que la mejor opción en este caso era modificar y editar directamente el dialecto que
utiliza el IS por defecto (http://wso2.org/claims) para adaptarlo al estándar OASIS correspondiente. Este
proceso de modificación o gestión del dialecto se puede realizar a través de la interfaz web que ofrece WSO2
(presentada en todas las capturas que se van añadiendo en la memoria) o directamente modificando el archivo
de configuración “claim-config.xml” (que podemos encontrar en la ruta <IS_HOME>\wso2is-
5.1.0\repository\conf).
En nuestro caso, se decidió abordar este problema editando directamente el archivo “claim-config.xml” (esto
nos permite replicar los resultados rápidamente en otro IS simplemente copiando este fichero, sin tener que
realizar la edición atributo a atributo), aunque todas las indicaciones necesarias para realizar el mismo
procedimiento por la interfaz web se pueden encontrar en el siguiente recurso [27] .
En apartados posteriores se detallará ampliamente como se realizó todo el proceso de edición y configuración.
Con respecto a la segunda opción que se muestra en la herramienta Claims (List), simplemente mencionar que
nos permite listar y examinar todos los dialectos actualmente definidos en el sistema. En la Captura 20.
Pantalla con el listado de dialectos existentes en el IS se pueden observar los dialectos que vienen creados por
defecto en el IS, mientras que en la Captura 21. Listado de claims (atributos) de un dialecto se muestran los
claims concretos de algunos de los dialectos existentes en el sistema.
Captura 20. Pantalla con el listado de dialectos existentes en el IS
42
Captura 21. Listado de claims (atributos) de un dialecto
Como se puede apreciar en la última captura, podemos editar o eliminar cada claim del dialecto a nuestro
antojo. Tal y como también se puede observar en la siguiente captura, la única característica que no se puede
modificar de un claim es el valor del campo Claim Uri, que identifica inequívocamente un claim en el sistema
y lo relaciona (mapea) con un atributo del LDAP embebido en el IS (Mapped Atribute).
Captura 22. Pantalla de gestión de atributos (claims)
Hasta aquí la introducción y análisis de las funcionalidades principales del IS que vamos a utilizar a lo largo
del desarrollo del proyecto. En los siguientes capítulos se explicará con alto nivel de detalle el procedimiento a
seguir para, utilizando las herramientas mencionadas en este capítulo y algunas otras que se explicarán
posteriormente, desarrollar el sistema de control de acceso adecuadamente.
43
2 Creación de un dialecto siguiendo la norma XSPA XACML de OASIS
En este punto de la memoria empezamos a abordar el tercer objetivo que establecimos en el proyecto, el de
crear un dialecto (recordemos, conjunto de claims o atributos que definen una entidad del IS) tomando como
referencia el estándar o norma de OASIS, XSPA XACML, centrado en el ámbito de la salud.
Como ya se comentó en la sección anterior, en la versión del IS que se está utilizando para desarrollar este
proyecto (la versión 5.1.0) no está implementada la funcionalidad de poder cambiar fácilmente (posiblemente
se pueda cambiar pero no hay una opción que lo facilite y supondría un mayor esfuerzo) el dialecto que utiliza
por defecto el IS para configurar las características de los nuevos usuarios creados (a través de la consola de
gestión). Por lo tanto, se decidió modificar el dialecto que usa por defecto (http://wso2.org/claims) para que
cumpliera la estructura de una entidad según dictan las directrices de la norma OASIS.
Este proceso se puede llevar a cabo de dos formas posibles:
Mediante la interfaz gráfica proporcionada por el servicio web del IS (https://localhost:9443/carbon/),
en el apartado Claim.
Modificando el archivo de configuración correspondiente a la gestión de los dialectos y claims del IS
<IS_HOME>\wso2is-5.1.0\repository\conf\claim-config.xml).
En nuestro caso, decidimos optar por modificar directamente el archivo claim-config.xml ya que, para
empezar, mediante la interfaz gráfica del IS no se puede modificar el campo claim-uri, que identifica el claim
dentro del IS y para terminar, porque resulta más cómo, sencillo y rápido gestionar directamente el archivo
XML.
A continuación se muestra una captura del archivo claim-config.xml editado (no la versión final) en el que
hemos deshabilitado (comentado) los claims que no nos interesan, reutilizado otros que si nos interesan e
introducido otros nuevos que necesitamos para hacer que en el dialecto “http://wso2.org/claims” aparezcan los
claims adecuados (específicos de la norma que nos ocupa):
Captura 23. Parte del dialecto que utiliza por defecto el IS editado con nuestros atributos
44
Vamos a proceder a explicar detalladamente cada uno de los elementos que aparecen en la captura anterior, de
forma que, aunque en nuestro caso vayamos a configurar los claims en función de un estándar concreto,
podamos crearlos para cualquier ámbito o propósito que se nos presente.
Lo primero que encontramos es la etiqueta <ClaimConfig>, que engloba a la etiqueta <Dialects>, y ésta a su
vez, que engloba a múltiples etiquetas <Dialect> (una por cada dialecto existente en el IS). Los dialectos que
están creados por defecto en el archivo claim-config.xml son los que aparecen también por defecto en el
apartado “Claims” de la interfaz web del IS (aunque el IS sólo nos deja utilizar el primero de ellos) cuando
pinchamos sobre la opción “List” (de hecho, la interfaz gráfica del IS toma los datos relacionados con los
dialectos y sus claims de este archivo).
Captura 24. Dialectos existentes por defecto en el IS (archivo de configuración claim-config.xml)
Dentro de cada etiqueta <Dialect> se recogen múltiples etiquetas <claim> (una por cada claim existente
dentro del dialecto correspondiente), y dentro de cada una de ellas se definen múltiples características
necesarias para identificar a dicho claim (algunas obligatorias y otras opcionales).
Captura 25. Definición de un atributo cualquiera (archivo de configuración claim-config.xml)
Vamos a proceder a explicar cada una de las etiquetas (características) que definen un claim:
ClaimURI: etiqueta que contiene una cadena que identifica y representa un tipo de claim dentro del
IS (se usa en las políticas y peticiones XACML para identificar de qué tipo es el valor/atributo
indicado). Es único y obligatorio. Es una especie de “intermediario” entre un dato/valor dado y el tipo
de atributo existente en LDAP. Aunque suele tener formato de URL (para seguir con el formato del
dialecto), en principio se puede representar con cualquier otro tipo de cadena de texto.
DisplayName (DisplayTag): etiqueta que contiene una cadena de texto que representa al ClaimURI.
Es único y obligatorio. Aparece en la interfaz web del IS cuando consultamos los claims que contiene
un dialecto (consultar Captura 21. Listado de claims (atributos) de un dialecto) o cuando creamos un
nuevo usuario y deseamos editar las características que lo definen (consultar Captura 22. Pantalla de
gestión de atributos (claims)).
45
AtributeID: junto con la etiqueta ClaimURI, son los parámetros más importantes. Es única y
obligatoria. Es el tipo de atributo, existente en el LDAP embebido del IS, con el que se mapea el tipo
referenciado por el ClaimURI. Resulta crítico que dicho valor exista en el LDAP, o si no existe (como
será nuestro caso), crearlo debidamente. Varios ClaimURI pueden hacer referencia al mismo
AtributeID.
Description: etiqueta que contiene una cadena de texto que resume la funcionalidad o uso del claim.
Es obligatoria.
Required: etiqueta opcional que indica si es obligatorio o no asignar un valor al claim (identifica si es
crítico o no dar un valor al claim para identificar la identidad en el IS).
DisplayOrder: etiqueta opcional que almacena un número que representa el orden en el que debe
aparecer el claim al listar los claims disponibles dentro de un dialecto.
SupportedByDefault: etiqueta opcional que hace que el claim sea mostrado o no cuando se realiza el
proceso de registro de la entidad en el IS.
RegEx: etiqueta opcional que contiene una expresión regular para validar el valor introducido en el
claim.
Una vez detallada la funcionalidad de todas las etiquetas de las que tenemos que hacer uso, ya estamos
preparados para editar el archivo claim-config.xml en función de la norma OASIS que estamos tomando como
referencia.
No obstante, y antes de “entrar en faena”, hay que tener en cuenta que este fichero es leído únicamente en el
primer arranque del Servidor de Identidad, por lo que cualquier cambio introducido en el archivo después de
ya haber arrancado el IS alguna vez no tendrá efecto ninguno (sería interesante investigar si existe otra opción
que permitiera hacer efectivos los cambios sin tener que re-arrancar el servidor de nuevo por primera vez).
Dicho esto, procedemos a detallar como se ha configurado el archivo claim-config.xml para que se adapte a
nuestro estándar. Lo primero que se ha hecho es analizar el estándar XSPA XACML para ver cuáles son los
atributos necesarios en un entorno o ámbito de la salud para poder identificar perfectamente la entidad que
quiere acceder a un recurso, cuáles son las características de dicha entidad, cuáles son las características del
recurso al que quiere acceder, qué quiere hacer con el recurso y cuáles son las circunstancias en las que se
quiere acceder al recurso (entorno).
En este punto, OASIS proporciona una tabla en la que se detalla cómo debe organizarse la información, las
restricciones existentes sobre cada tipo de información y los valores aceptables para cada uno. A partir de ella,
introduciremos o reutilizaremos los claims del archivo de configuración del IS para que en la interfaz web,
cada vez que creamos un nuevo usuario en el sistema, los atributos o características que definan a dicho
usuario sean las que marca el estándar.
Sin embargo, observando las imágenes aportadas a continuación y analizando todo lo que se ha ido
comentando en esta memoria, mientras que la norma define características tanto para los sujetos que desean
acceder al recurso como para el recurso al que se desea acceder como para el entorno en el que se localiza el
acceso, el IS de WSO2 sólo ofrece directamente la posibilidad de configurar claims para los usuarios (sujetos)
del sistema. Por ello, todas aquellas características complementarias que deseáramos incluir (asociadas a los
recursos a los que vamos a intentar acceder o al entorno en el que se va a realizar la petición) tendríamos que
definirlas directamente y de forma estática en el LDAP que tiene el IS embebido, de forma que el sistema
pudiera acceder a dicha información automáticamente cuando se realizara una petición sobre un determinado
recurso que hiciera uso de ella (realmente estos atributos deberían ser obtenidos a través del PIP adecuado).
46
Captura 26. Listado de atributos estándar de la norma OASIS utilizada como referencia
47
A partir de la tabla anterior y de la explicación que se ha realizado de las etiquetas que definen los claims, se
ha configurado el dialecto que usa por defecto el IS (http://wso2.org/claims) del fichero claim-config.xml de la
siguiente manera:
Captura 27. Resultado final del dialecto por defecto tras modificación (completo)
Como se puede observar, se han declarado todos y cada uno de los atributos recogidos en el documento de
OASIS (podemos encontrar el archivo íntegro en la ruta <IS_HOME>\wso2is-5.1.0\repository\conf)
relacionados con las características del sujeto que desea acceder a un determinado recurso. El único claim que
se ha reutilizado respecto de los que venían en el dialecto por defecto ha sido el correspondiente al rol del
usuario (http://wso2.org/claims/role), ya que, según está configurado el IS, es necesario que se defina así el
claim para que se realice correctamente la asociación de roles a los nuevos usuarios creados en el sistema.
En cuanto a los atributos relacionados con el recurso al que se desea acceder o con el entorno en el que se va a
producir la petición de acceso, comentar que se ha intentado configurar la estructura del LDAP de forma que
se pudieran contemplar también en el proceso de control de acceso, pero que no se ha logrado conseguir una
configuración adecuada que funcionara correctamente (sin modificar el código fuente de los módulos de los
que se compone el IS). Aún así, se estima que es perfectamente posible dar cabida a otros tipos de entidades en
el proceso de autorización del sistema configurando debidamente el LDAP embebido o el propio IS.
Antes de continuar, indicar que existen más dialectos definidos en el archivo claim-config.xml (los que vienen
por defecto definidos cuando se instala el IS), pero que no serán centro de nuestra atención principalmente
porque, como ya se comentó anteriormente, no se pueden utilizar realmente a la hora de configurar las
características de los nuevos usuarios creados.
48
De la mano de la edición del fichero de configuración de claims según nuestros intereses, surge la cuestión del
mapeo de los claims introducidos con atributos válidos existentes en el LDAP embebido en el IS por defecto,
ya que el rango de valores que podemos asignar al campo <attributeID> está acotado o restringido.
Por esto, se procedió a analizar la estructura del LDAP para determinar e identificar los atributos que vienen
precargados por defecto en el sistema y los que han sido introducidos por WSO2 para ver si se podía reutilizar
alguno en nuestro dialecto. En cuanto a los atributos que podemos encontrar por defecto en el LDAP,
comentar que vienen definidos en múltiples objectClasses, los cuales, a su vez, están recogidos en varios
esquemas (Ej. core, cosine o inetorgperson) que se incluyen por defecto en el LDAP (si quisiéramos utilizar
algún atributo más que ya existiera predefinido por LDAP, solamente tendríamos que insertar el esquema
correspondiente y ya tendríamos acceso al mismo). Dentro de este grupo de atributos, no se encontró un
conjunto de los mismos que nos permitiera poder almacenar la información necesaria según nuestras
necesidades (el listado de atributos que vienen definidos en los distintos esquemas que podemos encontrar en
LDAP, la mayoría distribuidos por OpenLDAP, puede encontrarse en el siguiente enlace:
http://www.zytrax.com/books/ldap/ape/#objectclasses). En cuanto a los atributos insertados por WSO2,
mencionar que se encuentran recogidos en varios archivos de extensión “.ldif” (recordemos, LDAP Data
Interchange Format) en la ruta <IS_HOME>\wso2is-5.1.0\repository\resources\identity\ldif. De nuevo,
ninguna de las definiciones de atributos que se realizan en ellos nos servía de cara a reutilizarlos en nuestro
proyecto.
A continuación se muestran varias capturas en la que se aprecian parte de archivos LDIF que tiene
introducidos WSO2 por defecto (archivos identityPerson.ldif, scimPerson.ldif y wso2Person.ldif). En ellos se
pueden observar varios atributos (gender, country, nickname, timeZone, etc) que permiten realizar el correcto
mapeo con el fichero claim-config.xml y que posibilitan su uso como características/atributos que representan
a las nuevas entidades que se definen en el IS.
Como ya se introdujo en el apartado de LDAP, LDIF es simplemente un formato que se utiliza para la
importación y exportación de datos independientemente del servidor LDAP que se esté utilizando.
Cada servidor LDAP tiene una o varias formas de almacenar físicamente sus datos, es por esto que LDIF
provee una manera de unificar la manera de tratar los datos y así poder migrarlos de un servidor a otro sin
importar qué clase de implementación es.
Captura 28. Archivos LDIF por defecto del IS
49
El uso de este formato es útil tanto para realizar copias de seguridad de los datos de un servidor LDAP, como
para importar pequeños cambios que se necesiten realizar manualmente en los datos, siempre manteniendo la
independencia de la implementación LDAP y de la plataforma donde esté instalada.
En nuestro caso, los únicos atributos que tendremos que manejar para realizar nuestro propio archivo LDIF
son los siguientes:
dn: <nombre distinguido>
La directiva dn simplemente describe la ruta hasta
cualquier entrada del DIT. Indica la entrada donde
queremos realizar los cambios.
changetype: modify
La directiva changetype va siempre a continuación de
una dn y detalla la operación que va a ser realizada en
la entrada. En nuestro caso la operación a llevar a
cabo será modifcar (modify) la información de la
entrada ya existente apuntada por la directiva dn.
add: attributeTypes ó add: objectClasses
La directiva add nos permite especificar de qué tipo
son los elementos que deseamos añadir, en nuestro
caso, nuevos tipos de atributos y un nuevo
“objectClass”.
attributeTypes: <valor> Las directivas attributeTypes y objectClasses nos
permiten detallar las características de los elementos
que queremos añadir a la entrada. objectClasses: <valor>
Operador ‘ – ‘
Para concatenar varias operaciones de modificación
(como es nuestro caso, que queremos realizar dos)
simplemente tenemos que hacer uso de una línea
separadora (-).
Tabla 4. Principales atributos de nuestros archivos LDIF
A la hora de definir las características de las directivas attributeTypes y objectClasses también podemos
detallar los elementos que vamos a usar:
attributeTypes
NAME: nombre del tipo de atributo a insertar
EQUALITY, SUBSTR, ORDERING: reglas de
coincidencia para la búsqueda del atributo.
SYNTAX: tipo del dato que se va a almacenar.
objectClasses
NAME: nombre del objectclass
DESC:descripción del objectclass
SUP: objectclass al que complementa (al que añade
sus atributos y funcionalidades)
STRUCTURAL, AUXILIARY o ABSTRACT: tipo
de objectClass.
MUST: atributos obligatorios
MAY: atributos opcionales
Tabla 5. Características principales de nuestros archivos LDIF
50
Llegados a este punto, la documentación proporcionada por WSO2 es escasa y no todo lo concisa que debiera,
por lo que se procedió a recabar información de fuentes externas y de recursos auxiliares (stackOverFlow y
recursos web) para poder seguir avanzando en el proceso de adaptación del dialecto que usa por defecto el IS.
De esta forma, se encontraron diversas técnicas para insertar los atributos deseados en el LDAP (para poder
realizar el mapeo correctamente con el archivo claim-config.xml), como por ejemplo, creando nuestro propio
archivo “.ldif”, e insertándolo directamente en el directorio correspondiente del IS (<IS_HOME>\wso2is-
5.1.0\repository\resources\identity\ldif) o accediendo directamente a la estructura del LDAP mediante un
software externo como es Apache Directory Server e insertándolo haciendo uso del mismo.
En nuestro caso, se decidió hacer uso del Apache Directory Server para realizar la inserción de los nuevos
atributos (necesarios para nuestro claim-config.xml) a través de archivos LDIF.
Antes de proceder a detallar el proceso de inserción de dichos archivos, vamos a proceder a realizar una
explicación del contenido de los mismos y a mostrar el resultado final que presentan (siguiendo las
indicaciones de la tabla de la Captura 26. Listado de atributos estándar de la norma OASIS proporcionada por
la norma que estamos tomando como referencia de OASIS).
Este es el resultado final que presentaría nuestro archivo LDIF personalizado en función de los atributos que
indica la norma OASIS que estamos tomando de base (podemos encontrar este archivo en la ruta
<IS_HOME>\wso2is-5.1.0\repository\resources\identity\ldif con el nombre oasisPerson.ldif).
Empezamos escribiendo “dn: cn=schema” para indicar la ruta hasta la entrada que queremos editar, después
de esto, indicamos que la acción que queremos realizar es la de modificar la información de la entrada y, tras
esto, para acabar de concretar, indicamos que queremos añadir nuevos tipos de atributos.
Tras esto, viene la definición de todos los tipos de atributos nuevos relacionados con el sujeto (subject) que
queremos introducir en el servidor LDAP (subject-id, organization-id, organization-name, hl7-permision,
purposeofuse) menos la del atributo role, que debemos reutilizar del objectClass “wso2Person” (archivo
wso2Person.ldif) para que a la hora de asignar los roles a los usuarios en la interfaz web del IS se asignen
correctamente a los usuarios y sea compatible con todas las pestañas y herramientas de las que dispone.
Por último, después de la definición de todos los tipos de atributos nuevos, vendría una nueva directiva de
adición, pero en este caso en vez de querer añadir atributos, añadimos un nuevo objectClass (oasisPerson), que
estará compuesto por todos y cada uno de los atributos que definimos anteriormente. Éste será de tipo
structural y complementará la información recogida por el objectClass identityPerson.
Captura 29. Archivo de configuración LDIF necesario para utilizar los nuevos atributos del dialecto
51
Pero, ¿a qué nos referimos cuando hablamos que nuestro objectClass complementa la información del otro
objectClass “identityPerson”? Vamos a intentar explicar esto de forma sencilla y escueta.
Como ya se mencionó en el apartado de introducción asociado al LDAP, todo servidor de directorios trae por
defecto una serie de esquemas predefinidos instalados (recordemos, un esquema es simplemente un conjunto
de objectClasses, es decir, un gran conjunto de atributos) y uno de ellos es precisamente el “inetOrgPerson”,
que detalla atributos genéricos para la definición de usuarios (subjects) en un determinado sistema.
Una vez aclarado esto, WSO2 simplemente define 3 nuevos objectClasses para completar la información
asociada a los usuarios que viene por defecto en el LDAP según sus intereses. Esto se consigue mediante una
estructura en cadena, es decir, concatenando los distintos objectClasses unos con otros a través de la directiva
“SUP”. De esta forma, el objectClass “wso2Person” complementa al “inetOrgPerson” (genérico), el
“scimPerson” complementa al “wso2Person”, el “identityPerson” complementa al “scimPerson” y el
“oasisPerson” (nuestro propio objectClass) complementa al “identityPerson”.
Pero ahora nos surge otra duda, ¿qué conseguimos con esto? La respuesta es sencilla, disponer de todas las
características y/o atributos que han ido añadiendo todos los objectClass que están por delante nuestra en la
cadena además de disponer de los nuestros propios personalizados en función de nuestros intereses.
A continuación se muestra una captura de pantalla de lo que sería el archivo LDIF asociado a los atributos que
define OASIS para los recursos (de igual forma, podríamos hacerlo también con los atributos que se definen
para el entorno). Recordemos que no se ha conseguido contemplar dichas entidades en el LDAP embebido,
luego no se tendrán en cuenta ni podremos usarlos.
Captura 30. Archivo de configuración LDIF para los atributos OASIS
Hay que destacar que el estándar OASIS define una serie de restricciones o requisitos que tienen que cumplir
cada uno de los atributos que usemos (recogidas en la tabla de la Captura 26. Listado de atributos estándar de
la norma OASIS) y que esto debería reflejarse en la configuración que hiciéramos en los archivos LDIF, pero
en nuestro caso no se va contemplar en este proyecto (ya que es una cuestión secundaria que no afecta al
desarrollo del proyecto). De esta forma, se tomará que por defecto todos los atributos son del mismo tipo
(string) y que presentan las mismas características comunes y genéricas.
oasisPerson identityPerson scimPerson wso2Person inetOrgPerson
52
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.
Captura 41. Ventana de edición de políticas
58
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
zona superior izquierda.
68
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.
74
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.
91
BIBLIOGRAFÍA
1 Recursos/Ensayos/papers del ámbito de la salud
[1] http://www.ncbi.nlm.nih.gov/pubmed/22440951
[2] http://www.ncbi.nlm.nih.gov/pubmed/21216720
[3] http://www.radiologyinfo.org/sp/info.cfm?pg=article-patient-privacy
[4] http://www.hl7.org/
[5] https://www.ihe.net/
2 XACML
[6] http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
[7] http://es.slideshare.net/rOzacC/xacml-37071981
3 SAML
[8] http://saml.xml.org/saml-specifications
4 SOAP
[9] https://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[10] http://www.desarrolloweb.com/articulos/1557.php
[11] http://es.slideshare.net/crack_708/rpc
[12] http://di002.edv.uniovi.es/~falvarez/WSDL.pdf
5 LDAP
[13] http://www.zytrax.com/books/ldap/ch2/
[14] http://www.zytrax.com/books/ldap/ch3/
[15] http://www.zytrax.com/books/ldap/apd/index.html#entry
[16] http://www.zytrax.com/books/ldap/ch8/#changetype
[17] https://directory.apache.org/studio/users-
guide/Apache_Directory_Studio_LDAP_Browser_User_Guide.pdf
[18] https://oav.net/mirrors/LDAP-ObjectClasses.html
92
6 OASIS
[19] https://www.oasis-open.org/org
[20] http://docs.oasis-open.org/xacml/xspa/v1.0/xacml-xspa-1.0-os.pdf
7 WSO2
[21] https://docs.wso2.com/display/IS510/Getting+Started
[22] http://stackoverflow.com/
[23] http://blog.gfi.es/wso2-como-plataforma-soa-open-source/
[24] http://wso2.com/products/carbon/
4 WSO2 Identity Server
[25] https://docs.wso2.com/display/IS510/WSO2+Identity+Server+Documentation
[26] http://wso2.com/products/identity-server/
[27] https://docs.wso2.com/display/IS510/Configuring+Claim+Dialects
[28] http://es.slideshare.net/wso2.org/gestin-de-identidades-y-control-de-acceso-en-los-servicios-usando-
wso2-identity-server
[29] http://es.slideshare.net/wso2.org/is-500intro?qid=b20868a1-2031-4f0f-81a6-
f4fc5897b588&v=&b=&from_search=1
[30] http://www.slideshare.net/wso2.org/wso2-product-release-webinar-wso2-identity-server-51
[31] https://www.youtube.com/watch?v=3g94WQbBLNo&feature=youtu.be
5 WSO2 Aplication Server
[32] https://docs.wso2.com/display/AS530/WSO2+Application+Server+Documentation
[33] https://docs.wso2.com/display/AS530/Getting+Started
6 Apache Directory Server
[34] http://directory.apache.org/
[35] http://hasini-gunasinghe.blogspot.com.es/2011/04/connecting-to-default-user-store-of.html
[36] http://hasini-gunasinghe.blogspot.com.es/2011/04/how-to-introduce-custom-object-class-to.html
93
7 SoapUI
[37] https://www.soapui.org/
[38] http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/209
8 Escenario de prueba
[39] http://dukechile.blogspot.com.es/2008/08/scwcd-el-descriptor-de-despliegue.html
[40] http://wso2.com/library/tutorials/2012/12/providing-xacml-fine-grained-authorization-webapps/
[41] http://insightforfuture.blogspot.com.es/2012/07/providing-xacml-fine-grained.html
[42] http://insightforfuture.blogspot.com.es/2012/07/providing-xacml-fine-grained_22.html
[43] http://insightforfuture.blogspot.com.es/2012/10/securing-exisiting-webapp-using.html
[44] https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.
entitlement.filter/
9 Investigaciones relacionadas con WSO2
[45] Alberto Rodríguez Blázquez, Francisco José Rodríguez Olid, Solución WSO2: Carbon, en:
Procesamiento Distribuido, Máster en Ingeniería de Telecomunicación, 2016
[46] Antonio Padilla Esquivel, Francisco José Pérez Díaz, WSO2 Complex Event Processor, en:
Procesamiento Distribuido, Máster en Ingeniería de Telecomunicación, 2016
[47] Fco. Javier Vargas, María Silvestre, María Dolores Tristán, Servidor de Análisis de Datos (DAS), en:
Procesamiento Distribuido, Máster en Ingeniería de Telecomunicación, 2016
[48] Daniel López Gómez, Francisco Jesús Marchal Cebador, WSO2 Enterprise Service Bus, en:
Procesamiento Distribuido, Máster en Ingeniería de Telecomunicación, 2016
[49] Álvaro Martín, Rafael Ocaña y Lourdes Vaquera, WSO2 Message Broker vs Apache Kafka, en:
Procesamiento Distribuido, Máster en Ingeniería de Telecomunicación, 2016
10 Otros
[50] http://scienceresearch.com/scienceresearch/
[51] http://bib.us.es/estudia_e_investiga/guias/tfg
[52] http://bibing.us.es/proyectos/buscar/%20/en/todo/and//en/todo/limitado_a/tg2/entre/1970/y/2016///1
94
95
ANEXOS
ANEXO A. SERVIDOR DE IDENTIDAD DE WSO2 (VERSIÓN 5.1.0)
SET DE CARACTERÍSTICAS COMPLETO
System and User Identity Management
API to integrate identity management to any application
Multi-factor authentication
Single Sign-On (SSO) via OpenID, SAML2 and OpenID Connect
SSO bridging between on-premise systems and cloud apps
Credential mapping across different protocols
Auditing via XDAS
Delegation via OAuth 1.0a, OAuth 2.0, and WS-Trust
Federation via OpenID, SAML2, OpenID Connect and Passive STS
Integration with Microsoft SharePoint with Passive STS support
Implement REST security with OAuth 2.0/OpenID Connect and XACML
Implement REST security with OpenID Connect
Out-of-the-box integration with Google Apps and Salesforce
Customizable login pages for OpenID, OAuth, OpenID Connect, SAML2, and Passive STS
User and Groups Provisioning
Support for SCIM 1.1 standard
OAuth 2.0 authentication for SCIM
Automatic provisioning of users to "Salesforce/Google Apps" or via SPML/SCIM
Just-in-time provisioning can be used to create identities "on the fly"
User and Groups Management
Web-based application for users, for profile, password, and service providers management
Flexible support for user stores, either built-in LDAP (powered by ApacheDS) or external LDAP,
Microsoft Active Directory, or any JDBC database
Flexible profile management for users supporting multiple profiles per user
Multiple user store support
Per tenant user stores
Ability to link multiple user profiles belonging to a single user
Account locking on failed user attempts
Password policies
Account recovery with email and secret questions
FIDO 2 factor authentication
96
Entitlements Management
Role based access control (RBAC)
Attribute or claim based access control via XACML, WS-Trust, OpenID, and claim management
Fine-grained policy based access control via XACML
Advanced entitlement auditing and management
Entitlement management for any REST or SOAP calls
XACML 2.0/3.0 Support
User-friendly interface for policy editing
Multiple Policy Information Point (PIP) support
TryIt tool for exploring policy impact
Policy distribution to various Policy Decision Points (PDPs)
Policy decision and attribute caching
High performance network protocol (over Apache Thrift) for PEP/PDP interaction
Notifications of policy updates
Policy Administration Point (PAP) to manage multiple Policy Decision Points (PDP)
Customizable policy administration UI
Lightweight, Developer Friendly and Easy to Deploy
Complete SOAP API for integrating/embedding into any application or system
Pluggable workflows for privileged operations
Extensibility for pluggable authenticators, alternative user stores, XACML/SAML extension points,
and more
Clustering for high available deployment
Choice of deployment to on-premise servers, private cloud, or managed cloud, without configuration
changes
Integrated to WSO2 Enterprise Service Bus for authorization and all WSO2 Carbon products for
authentication
Manage and Monitor
Comprehensive management and monitoring Web console with enterprise-level security and SAML2
SSO
Built-in collection and monitoring of standard access and performance statistics
JMX MBeans for key metrics monitoring and management
Integrates with WSO2 Business Activity Monitor for operational audit and KPI monitoring and
management
Flexible logging support with integration to enterprise logging systems
Centralized configuration management across different deployment environments with life cycles and
versioning with integration to WSO2 Governance Registry
RECURSOS Y ARCHIVOS DE CONFIGURACIÓN UTILIZADOS
Archivo: carbon.xml - Directorio: <IS_HOME>\wso2is-5.1.0\repository\conf
Archivo: user-mgt.xml – Directorio: <IS_HOME>\wso2is-5.1.0\repository\conf
Archivo: claim-config.xml - Directorio: <IS_HOME>\wso2is-5.1.0\repository\conf
Archivo: embedded-ldap.xml – Directorio: <IS_HOME>\wso2is-5.1.0\repository\conf\identity
Archivo: oasisPerson.ldif – Directorio: <IS_HOME>\wso2is-5.1.0\repository\resources\identity\ldif
Archivos: MiPrimeraPolitica.xml, MiSegundaPolitica.xml y Entitlement_Filter_Sample_Policy.xml –
Directorio: <IS_HOME>\wso2is-5.1.0\repository\resources\identity\policies\xacml\default
97
Archivos de configuración modificados/creados
CARBON.XML
<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
Copyright (c) 2015, WSO2 Inc. (http://www.wso2.org) All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!--
This is the main server configuration file
${carbon.home} represents the carbon.home system property.
Other system properties can be specified in a similar manner.
-->
<Server xmlns="http://wso2.org/projects/carbon/carbon.xml">
<!--
Product Name
-->
<Name>WSO2 Identity Server</Name>
<!--
machine readable unique key to identify each product
-->
<ServerKey>IS</ServerKey>
<!--
Product Version
-->
<Version>5.1.0</Version>
98
<!--
Host name or IP address of the machine hosting this server
e.g. www.wso2.org, 192.168.1.10
This is will become part of the End Point Reference of the
services deployed on this server instance.
-->
<HostName>localhost</HostName>
<!--
Host name to be used for the Carbon management console
-->
<MgtHostName>localhost</MgtHostName>
(...)
<!--
If this parameter is set, the ?wsdl on an admin service will
not give the admin service wsdl.
-->
<HideAdminServiceWSDLs>false</HideAdminServiceWSDLs>
<!-- WARNING-Use With Care! Uncommenting bellow parameter would
expose all AdminServices in HTTP transport.
With HTTP transport your credentials and data routed in public
channels are vulnerable for sniffing attacks.
Use bellow parameter ONLY if your communication channels are
confirmed to be secured by other means
-->
<!--HttpAdminServices>*</HttpAdminServices-->
(...)
</Server>
99
CLAIM-CONFIG.XML <!--
~ Copyright (c) 2005-2011, WSO2 Inc. (http://www.wso2.org) All Rights Reserved.
~
~ WSO2 Inc. licenses this file to you under the Apache License,
~ Version 2.0 (the "License"); you may not use this file except
~ in compliance with the License.
~ You may obtain a copy of the License at
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing,
~ software distributed under the License is distributed on an
~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~ KIND, either express or implied. See the License for the
~ specific language governing permissions and limitations
~ under the License.
-->
<ClaimConfig>
<Dialects>
<Dialect dialectURI="http://wso2.org/claims">
<Claim>
<ClaimURI>urn:oasis:names:tc:xacml:1.0:subject:subject-
id</ClaimURI>
<DisplayName>Oasis Subject ID</DisplayName>
<AttributeID>subject-id</AttributeID>
<Description>Is the name of the user as required by
HIPAA Privacy Disclosure Accounting</Description>
<Required />
<SupportedByDefault />
</Claim>
<Claim>
<ClaimURI>urn:oasis:names:tc:xspa:1.0:subject:organizati
on</ClaimURI>
<DisplayName>Oasis Organization</DisplayName>
<AttributeID>organization-name</AttributeID>
<Description>Organization the requesting user belongs to
as required by HIPAA Privacy Disclosure
Accounting</Description>
<Required />
<SupportedByDefault />
</Claim>
100
<Claim>
<ClaimURI>urn:oasis:names:tc:xspa:1.0:subject:organizati
on-id</ClaimURI>
<DisplayName>Oasis Organization ID</DisplayName>
<AttributeID>organization-id</AttributeID>
<Required />
<Description>Unique identifier of the consuming
organization and/or facility</Description>
<SupportedByDefault />
</Claim>
<Claim>
<ClaimURI>urn:oasis:names:tc:xspa:1.0:subject:hl7:permis
sion</ClaimURI>
<DisplayName>Oasis HL7 Permission</DisplayName>
<AttributeID>hl7-permission</AttributeID>
<Description>Refer to [HL7-PERM] and its OID
representation</Description>
<Required />
<SupportedByDefault />
</Claim>
<Claim>
<ClaimURI>http://wso2.org/claims/role</ClaimURI>
<DisplayName>Oasis Role</DisplayName>
<AttributeID>role</AttributeID>
<Description>This attribute holds roles required by the
servicing organization to grant access to a specific
resource</Description>
<SupportedByDefault />
<ReadOnly />
</Claim>
<Claim>
<ClaimURI>urn:oasis:names:tc:xspa:1.0:subject:purposeofu
se</ClaimURI>
<DisplayName>Oasis Subject Purpose of use</DisplayName>
<AttributeID>purposeOfUse</AttributeID>
<Description>TREATMENT,PAYMENT,OPERATIONS,EMERGENCY,MARK
ETING,RESEARCH,REQUEST,PUBLICHEALTH</Description>
<SupportedByDefault />
</Claim>
101
<Claim>
<ClaimURI>urn:oasis:names:tc:xacml:1.0:resource:resource
-id</ClaimURI>
<DisplayName>Oasis Resource ID</DisplayName>
<AttributeID>resource-id</AttributeID>
<Description>Unique identifier of the resource defined
by and controlled by the servicing
organization</Description>
</Claim>
<Claim>
<ClaimURI>urn:oasis:names:tc:xspa:1.0:resource:hl7:type<
/ClaimURI>
<DisplayName>Oasis Resource HL7 Type</DisplayName>
<AttributeID>hl7-type</AttributeID>
<Description>For minimum interoperability set of objects
and supporting actions refer to HL7-PERM and their OID
representations</Description>
</Claim>
</Dialect>
<Dialect
dialectURI="http://schemas.xmlsoap.org/ws/2005/05/identity">
(…)
</Dialect>
<Dialect dialectURI="http://schema.openid.net/2007/05/claims">
(…)
</Dialect>
<Dialect dialectURI="http://axschema.org">
(…)
</Dialect>
<Dialect dialectURI="urn:scim:schemas:core:1.0">
(…)
</Dialect>
<Dialect dialectURI="http://wso2.org/oidc/claim">
(…)
</Dialect>
</Dialects>
</ClaimConfig>
102
EMBEDDED-LDAP.XML
<?xml version="1.0" encoding="UTF-8"?>
<!-- *
* Copyright 2004,2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
* -->
<!--
All carbon based products comes with a LDAP user store.
For this we use an embedded LDAP in carbon based products.
This file contains necessary configurations to control the behavior of embedded
LDAP.
You may use this file to enable, disable LDAP server, configure connection admin
password, etc ...
In addition to embedded-ldap server configurations this file also has Kerberos
KDC (Key Distribution Center)specific configurations.
-->
<EmbeddedLDAPConfig>
<!--
LDAP server configurations
==========================
This section contains LDAP server specific configurations.
Property Usage
======= ====
enable If true the embedded LDAP server will start
when server starts up.
Else embedded LDAP server will not start.
Thus user has to use a different user store.
103
instanceid An id given to the LDAP server instance.
connectionPassword The password of the admin.
(uid=admin,ou=system)
workingDirectory Location where LDAP will store its schema
files.
AdminEntryObjectClass Object class which encapsulate attributes
needed by claims.
allowAnonymousAccess Should allow users to access LDAP server
without credentials. Default false.
accessControlEnabled Should access control be enabled among
partitions. Default true.
saslHostName Default host name to be used in SASL (Simple
Authentication and Security Layer).
This property comes from apacheds
implementation itself.
saslPrincipalName Default SASL principal name. Again this
property also comes from apacheds
implementation itself.
-->
<EmbeddedLDAP>
<Property name="enable">true</Property>
<Property
name="port">${Ports.EmbeddedLDAP.LDAPServerPort}</Property>
<Property name="instanceId">default</Property>
<Property name="connectionPassword">admin</Property>
<Property name="workingDirectory">.</Property>
<!-- <Property name = "AdminEntryObjectClass">
identityPerson</Property> -->
<Property name="AdminEntryObjectClass">oasisPerson</Property>
<Property name="allowAnonymousAccess">false</Property>
<Property name="accessControlEnabled">true</Property>
<Property name="denormalizeOpAttrsEnabled">false</Property>
<Property name="maxPDUSize">2000000</Property>
<Property name="saslHostName">localhost</Property>
<Property name = "saslPrincipalName"> ldap/[email protected]
</Property>
</EmbeddedLDAP>
(...)
</EmbeddedLDAPConfig>
104
USER-MGT.XML
<!--
~ Copyright WSO2, Inc. (http://wso2.com)
~
~ Licensed under the Apache License, Version 2.0 (the "License");
~ you may not use this file except in compliance with the License.
~ You may obtain a copy of the License at
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing, software
~ distributed under the License is distributed on an "AS IS" BASIS,
~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~ See the License for the specific language governing permissions and
~ limitations under the License.
-->
<UserManager>
<Realm>
<Configuration>
<AddAdmin>true</AddAdmin>
<AdminRole>admin</AdminRole>
<AdminUser>
<UserName>admin</UserName>
<Password>admin</Password>
</AdminUser>
<EveryOneRoleName>everyone</EveryOneRoleName> <!-- By
default users in this role sees the registry root -->
<Property name="isCascadeDeleteEnabled">true</Property>
<Property name = "dataSource"> jdbc/WSO2CarbonDB
</Property>
</Configuration>
(...)
<!--
Following user manager is used by Identity Server (IS) as its
default user manager. IS will do token replacement when building the
product. Therefore do not change the syntax.If "kdcEnabled"
parameter is true, IS will allow service principle management. Thus
"ServicePasswordJavaRegEx", "ServiceNameJavaRegEx" properties
control the service name format and service password formats. In
case if user core cache domain is needed to identify uniquely set
105
property <Property name="UserCoreCacheIdentifier"> domain
</Property>
-->
<UserStoreManager
class="org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager"
>
<Property
name="TenantManager">org.wso2.carbon.user.core.tenant.CommonHy
bridLDAPTenantManager</Property>
<Property
name="ConnectionURL">ldap://localhost:${Ports.EmbeddedLDAP.LDA
PServerPort}</Property>
<Property name="ConnectionName">uid=admin,ou=system</Property>
<Property name="ConnectionPassword">admin</Property>
<Property
name="UserSearchBase">ou=Users,dc=wso2,dc=org</Property>
<!-- <Property name = "UserEntryObjectClass">
identityPerson</Property> -->
<Property name="UserEntryObjectClass">oasisPerson</Property>
<Property name="UserNameAttribute">uid</Property>
<Property
name="UserNameSearchFilter">(&(objectClass=person)(uid=?))
</Property>
<Property
name="UserNameListFilter">(objectClass=person)</Property>
<Property name="DisplayNameAttribute"/>
<Property name="ReadGroups">true</Property>
<Property name="WriteGroups">true</Property>
<Property
name="GroupSearchBase">ou=Groups,dc=wso2,dc=org</Property>
<Property name="GroupEntryObjectClass">groupOfNames</Property>
<Property name="GroupNameAttribute">cn</Property>
<Property name="GroupNameSearchFilter">
(&(objectClass=groupOfNames)(cn=?))</Property>
<Property name="GroupNameListFilter">
(objectClass=groupOfNames)</Property>
<Property name="MembershipAttribute">member</Property>
<Property name="BackLinksEnabled">false</Property>
<Property name="UsernameJavaRegEx">[a-zA-Z0-9._-
|//]{3,30}$</Property>
<Property name="UsernameJavaScriptRegEx">
^[\S]{3,30}$</Property>
<Property name="UsernameJavaRegExViolationErrorMsg">Username
pattern policy violated</Property>
<Property name="PasswordJavaRegEx"> ^[\S]{5,30}$</Property>
<Property name="PasswordJavaScriptRegEx">
^[\S]{5,30}$</Property>
<Property name="PasswordJavaRegExViolationErrorMsg">Password
106
length should be within 5 to 30 characters</Property>
<Property name="RolenameJavaRegEx">[a-zA-Z0-9._-
|//]{3,30}$</Property>
<Property name="RolenameJavaScriptRegEx">
^[\S]{3,30}$</Property>
<Property name="SCIMEnabled">true</Property>
<Property name="IsBulkImportSupported">false</Property>
<Property name="EmptyRolesAllowed">true</Property>
<Property name="PasswordHashMethod">PLAIN_TEXT</Property>
<Property name="MultiAttributeSeparator">,</Property>
<Property name="MaxUserNameListLength">100</Property>
<Property name="MaxRoleNameListLength">100</Property>
<Property name="kdcEnabled">false</Property>
<Property name="defaultRealmName">WSO2.ORG</Property>
<Property name="UserRolesCacheEnabled">true</Property>
<Property name="ConnectionPoolingEnabled">false</Property>
<Property name="LDAPConnectionTimeout">5000</Property>
<Property name="ReadTimeout"/>
<Property name="RetryAttempts"/>
</UserStoreManager>
<AuthorizationManager
class="org.wso2.carbon.user.core.authorization.JDBCAuthorizationMana
ger">
<Property
name="AdminRoleManagementPermissions">/permission</Property>
<Property name="AuthorizationCacheEnabled">true</Property>
<Property name="GetAllRolesOfUserEnabled">false</Property>
</AuthorizationManager>
</Realm>
</UserManager>
(...)
107
OASISPERSON.LDIF
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.37505.1.103
NAME 'subject-id'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
attributeTypes: ( 1.3.6.1.4.1.37505.1.104
NAME 'organization-id'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
attributeTypes: ( 1.3.6.1.4.1.37505.1.105
NAME 'organization-name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
attributeTypes: ( 1.3.6.1.4.1.37505.1.106
NAME 'hl7-permission'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
attributeTypes: ( 1.3.6.1.4.1.37505.1.107
NAME 'purposeofuse'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
-
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.37505.1.102
NAME 'oasisPerson'
DESC 'oasisPerson'
SUP identityPerson
STRUCTURAL
MAY ( subject-id $ organization-id $ organization-name $ hl7-permission $
purposeofuse )
)
-
108
MIPRIMERAPOLITICA.XML
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
PolicyId="MiPrimeraPolitica"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-
applicable" Version="1.0">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
MiRecurso</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-
id" Category="urn:oasis:names:tc:xacml:3.0:attribute-
category:resource"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true">
</AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
<Rule Effect="Permit" RuleId="Rule-1">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-
equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
read
</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-
id" Category="urn:oasis:names:tc:xacml:3.0:attribute-
category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true">
</AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
109
<Condition>
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of">
<Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-
equal"></Function>
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
ESI
</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xspa:1.0:subject:organization"
Category="urn:oasis:names:tc:xacml:1.0:subject-
category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true">
</AttributeDesignator>
</Apply>
</Condition>
</Rule>
<Rule Effect="Deny" RuleId="Deny-Rule"></Rule>
</Policy>
MISEGUNDAPOLITICA.XML
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
PolicyId="MiSegundaPolitica"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-
applicable" Version="1.0">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
Medic
</AttributeValue>
<AttributeDesignator AttributeId=http://wso2.org/claims/role
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-
subject"
DataType=http://www.w3.org/2001/XMLSchema#string
MustBePresent="true"></AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
110
<Rule Effect="Permit" RuleId="Rule-1">
<Target>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-
equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
write
</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-
category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"></AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-
equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
Study
</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xspa:1.0:subject:purpose
ofuse" Category="urn:oasis:names:tc:xacml:1.0:subject-
category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"></AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
<Rule Effect="Deny" RuleId="Deny-Rule"></Rule>
</Policy>
111
ENTITLEMENT_FILTER_SAMPLE_POLICY.XML
<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
PolicyId="Entitlement_Filter_Sample_Policy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-
applicable" Version="1.0">
<Target></Target>
<Rule Effect="Permit" RuleId="Rule1">
<Target>
<AnyOf>
<AllOf>
<Match MatchId =
"urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
/Entitlement_Sample_WebApp/protected.jsp
</AttributeValue>
<AttributeDesignator
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-
id" Category="urn:oasis:names:tc:xacml:3.0:attribute-
category:resource"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true">
</AttributeDesignator>
</Match>
<Match MatchId =
"urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType =
"http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
<AttributeDesignator AttributeId =
"urn:oasis:names:tc:xacml:1.0:action:action-id"
Category="urn:oasis:names:tc:xacml:3.0:attribute-
category:action"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true">
</AttributeDesignator>
</Match>
112
<Match MatchId =
"urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType =
"http://www.w3.org/2001/XMLSchema#string">Cuidar</AttributeVal
ue>
<AttributeDesignator AttributeId =
"http://wso2.org/claims/purposeOfUse"
Category="urn:oasis:names:tc:xacml:1.0:subject-
category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true">
</AttributeDesignator>
</Match>
</AllOf>
</AnyOf>
</Target>
</Rule>
</Policy>
113
ANEXO B. SERVIDOR DE APLICACIONES DE WSO2 (VERSIÓN 5.3.0)
SET DE CARACTERÍSTICAS COMPLETO
Host & Manage Web Applications
Run any standard WAR file or exploded WAR file offering applications and/or RESTful services
Complete administration console for WAR files
Integrated security management for applications
Basic Auth integration to LDAP, Google Auth, OpenID and other external user stores
Fine grained authorization through integration with WSO2 Enterprise Service Bus and WSO2 Identity
Server
OpenID relying party capabilities
Single-Sign On (SSO) across applications through SAML2
Datasource management for scalable data management
Support for JavaEE 6 Web profile
Session persistence to permanently store HTTP session details enabling failover and load balancing
across a cluster of application servers
Virtual hosting to maintain multiple domain names under the same IP address
Full-duplex communication via a single TCP connection through WebSocket 1.1 API
Host & Manage Web Services
Support for SOAP services and JAX-WS services
Support for RESTful services with JAX-RS, HTTP/JSON using HTTP methods and status codes
Integrates Apache Axis2 and Apache CXF Web services engines
All key WS-* standards supported including SOAP 1.1, SOAP 1.2, MTOM, XOP, SwA, WSDL 1.1,
WSDL 2.0, WS-Addressing, WS-Security, WS-Trust, WS-SecureConversation, WS-Policy, WS-
PolicyAttachment, WS-SecurityPolicy, WS-ReliableMessaging, WS-Discovery
Multi-transport service access via HTTP, HTTPS, JMS, VFS and SMTP
Flexible WS-SecurityPolicy configuration for common security patterns
Comprehensive user management via integration to WSO2 Identity Server
In built support for data services
Clustering and HTTP session replication for web services
Host & Manage Jaggery Apps
Jaggery is a framework for writing apps using Javascript on the server, JSON for communication and
Javascript on the client. Seehttp://jaggeryjs.org/
Deploy any Jaggery webapp or RESTful Web service
Secure and manage Jaggery apps with enterprise security features in WSO2 Application Server
Enforce Enterprise Security for Apps & Services
Integrated security management for applications
Basic authentication integration to LDAP, Google Auth, OpenID and other external user stores
Integration with WSO2 Enterprise Service Bus and WSO2 Identity Server allowing fine grained
authorization
OpenID relying party capabilities
SAML2 providing SSO across applications
Integrates to enterprise identity management systems via LDAP or via WSO2 Identity Server
114
Rich Context for Programming Scalable Applications & Services
Comprehensive easy-to-use APIs for developing enterprise applications relieving developers from the
complexities of security, data management, metadata management and system performance
Integrates to enterprise identity management systems via LDAP or via WSO2 Identity Server
Distributed caching for large scale application and service performance
Shared metadata registry and repository for any application metadata via embedded registry or WSO2
Governance Registry
JNDI provider for accessing shared data source and other resources
Distributed sharing of caches and metadata across applications and services
Deployment synchronization of applications and services across multiple server instances
Lazy loading of web applications and services
Elastically Scalable, Cloud-Enabled Multi-Tenant Application Server Platform
Easily build and deploy SaaS applications with WSO2 Application Server as a shared, multi-tenant,
elastically scaling platform
Implement multi-tenant Apache Tomcat applications using rich context APIs
Build self-service SaaS applications with integrated billing and metering capabilities
Deploy as “Application Server as a Service” for the enterprise
Lightweight, Developer Friendly and Easy to Deploy
Easy to develop, debug and deploy both applications and services with tools for message tracing and
interactive testing with TryIt capabilities
Extremely simple security management
Server customization via feature provisioning of any WSO2 middleware capability
Choice of deployment to on-premise servers, private cloud, or managed cloud
Integrated with SVN, Maven, Ant and other standard tools for development and deployment
Integrated to WSO2 Developer Studio, Eclipse-based IDE for all WSO2 products
Manage & Monitor
Comprehensive management and monitoring Web console with enterprise-level security including
Role Based Access Control (RBAC)
Built-in collection and monitoring of standard access and performance statistics
JMX MBeans for all key metrics monitoring and management features
Integrates with WSO2 Business Activity Monitor for operational audit and KPI/SLA monitoring and
management
Flexible logging support with integration to enterprise logging systems
Centralized configuration management across different environments with lifecycles and versioning
with integration to WSO2 Governance Registry
RECURSOS Y ARCHIVOS DE CONFIGURACIÓN UTILIZADOS
ARCHIVOS DE CONFIGURACIÓN GENERAL:
Archivo: carbon.xml - Directorio: <AS_HOME>\wso2as-5.3.0\repository\conf
115
APLICACIÓN WEB GENÉRICA:
Archivo: index.html – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\PaginaWebPrueba
Archivo: style.css – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\PaginaWebPrueba\style
Archivo: web.xml – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\PaginaWebPrueba\WEB-INF
Archivo: volcano.mp4 – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\PaginaWebPrueba\Video
Archivo: MANIFEST.MF – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\PaginaWebPrueba\META-INF
Archivos: body.png y dark.png – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\PaginaWebPrueba\Images
APLICACIÓN WEB ESCENARIO DE PRUEBA:
Archivos: error.jsp, index.jsp y protected.jsp – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\Entitlement_Sample_WebApp
Archivo: style.css – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\Entitlement_Sample_WebApp\style
Archivo: web.xml – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\Entitlement_Sample_WebApp\WEB-INF
Archivo: javascript.js – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\Entitlement_Sample_WebApp\Scripts
Archivo: MANIFEST.MF – Directorio: <AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\Entitlement_Sample_WebApp\META-INF
Archivos: body, dark, flat2 (png) y flat1, flat2, tecno, tecno2 (jpg) – Directorio:
<AS_HOME>\wso2as-
5.3.0\repository\deployment\server\webapps\Entitlement_Sample_WebApp\Images
116
Archivos de configuración modificados/creados
CARBÓN.XML
<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
Copyright (c) 2015, WSO2 Inc. (http://www.wso2.org) All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!--
This is the main server configuration file
${carbon.home} represents the carbon.home system property.
Other system properties can be specified in a similar manner.
-->
<Server xmlns="http://wso2.org/projects/carbon/carbon.xml">
<!--
Product Name
-->
<Name>WSO2 Application Server</Name>
<!--
machine readable unique key to identify each product
-->
117
<ServerKey>AS</ServerKey>
<!--
Product Version
-->
<Version>5.3.0</Version>
(...)
<!--
Ports used by this server
-->
<Ports>
<!-- Ports offset. This entry will set the value of the ports
defined below to the define value + Offset.
e.g. Offset=2 and HTTPS port=9443 will set the effective HTTPS
port to 9445
-->
<Offset>1</Offset>
(...)
</Server>
118
Archivos y recursos de la Aplicación Web Genérica
INDEX.HTML
<!-- <%@ page contentType="text/html;charset=UTF-8" language="java" %>-->
<html>
<head>
<meta charset="UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15">
<link rel="stylesheet" type="text/css" href="style/style.css">
</head>
<body>
<video preload="preload" autoplay="true" loop="loop" id="bgvid">
<source src="Video/Volcano.mp4" type="video/mp4">
</video>
<div id="header">
<h1>Simple WebApplication</h1>
<div id="acronym">
<p>Aplication Server/Identity Server Autorization Test</p>
</div>
</div>
<section class="info">
<div class="links">
<p id="intro">Useful links (Links útiles):</p>
<div class="links2">
<p ><a href="http://wso2.com/products/identity-
server/"class="text">WSO2 Identity Server</a></p>
<p ><a href="http://wso2.com/products/application-
server/"class="text">WSO2 Application Server</a></p>
<p ><a
href="https://docs.wso2.com/display/IS510/WSO2+Identity+
Server+Documentation"class="text">WSO2 Identity Server
Documentation</a></p>
<p ><a
href="https://docs.wso2.com/display/AS530/WSO2+Applicati
on+Server+Documentation"class="text">WSO2 Application
Server Documentation</a></p>
</div>
</div>
</section>
119
<div id="footer">
<p>Contact: [email protected]</p>
</div>
</body>
</html>
STYLE.CSS
*{
margin: 0px;
font-family: sans-serif;
max-width: 100%;
right: 0;
}
#header{
color: white;
text-align: center;
height: 400px;
font-size: 1.3em;
}
h1{
margin:auto;
width: 40%;
position: relative;
top: 35%;
border-width: 5px;
border-color: white;
border-style: solid;
}
#bgvid{
position: fixed;
top: 50%;
left: 50%;
min-width: 100%;
min-height: 100%;
width: auto;
height: auto;
z-index: -100;
120
-ms-transform: translateX(-50%) translateY(-50%);
-moz-transform: translateX(-50%) translateY(-50%);
-webkit-transform: translateX(-50%) translateY(-50%);
transform: translateX(-50%) translateY(-50%);
}
.info{
width: 100%;
height: 250px;
background-color: white;
}
#acronym{
position: relative;
width: 50%;
margin:auto;
text-align: center;
font-size: 1.1em;
color: white;
top: 45%;
}
.button{
position: relative;
top: 200px;
text-decoration: none;
background-color: rgba(0,0,0,0.6);
border-width: 5px;
border-right: 0px;
border-left: 0px;
border-top: 0px;
font-weight: bolder;
color: white;
height: 50px;
width: 150px;
border-radius: 5px;
border-color: rgba(0,0,0,0.8);
}
.button:hover{
border-bottom: 0px;
border-color: rgba(0,0,0,0.6);
121
top: 205px;
height: 45px;
cursor: pointer;
}
.links{
position: relative;
top: 30px;
left: 20px;
width: 100%;
}
.links2{
position: relative;
left: 20px;
font-size: 1.5em;
}
#intro{
position: relative;
font-weight: bolder;
top: 5px;
margin: 10px;
font-size: 2em;
}
.text{
position: relative;
font-weight: bolder;
top: 5px;
-webkit-transition: color,0.4s;
}
.text:hover{
color: red;
}
a{
text-decoration: none;
color: black;
}
122
#footer{
width: 100%;
height: 100px;
background-color: black;
color: white;
text-align: center;
}
#footer p{
position: relative;
top: 45%;
}
MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.4
Created-By: 1.6.0_01-b06 (Sun Microsystems Inc.)
RECURSOS VARIOS (IMÁGENES Y VIDEOS)
* Recogidos en el CD *
123
Archivos y recursos de la Aplicación Web del escenario de prueba
INDEX.JSP
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
<meta charset="UTF-8">
<meta http-equiv="Content-Type" content="text/html; charset=iso-
8859-15">
<script
src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.0/jquery.min.
js"></script>
<script src="Scripts/javascript.js"></script>
<link rel="stylesheet" type="text/css" href="style/style.css">
<title>AS/IS Test</title>
</head>
<body>
<nav id="menu">
<ul>
<li>
<p class="servers"><a
href="http://wso2.com/products/identity-
server/"class="text">WSO2 Identity Server</a></p>
</li>
<li>
<p class="servers"><a
href="http://wso2.com/products/application-
server/"class="text">WSO2 Application Server</a></p>
</li>
<li>
<p class="servers"><a
href="https://docs.wso2.com/display/IS510/WSO2+Identity+
Server+Documentation"class="text">WSO2 Identity Server
Documentation</a></p>
</li>
<li>
<p class="servers"><a
href="https://docs.wso2.com/display/AS530/WSO2+Applicati
on+Server+Documentation"class="text">WSO2 Application
Server Documentation</a></p>
</li>
</ul>
</nav>
124
<div id="header">
<h1>AS-IS Autentication/Autorization Test</h1>
<div id="acronym">
<p>Click the button for identificating yourself</p>
<div id="links">
<p>~For useful links, hover left~</p>
</div>
</div>
<div id="section">
<form action="protected.jsp" method="GET">
<input type="submit" name="enviar" value="Access"
class="button" />
</form>
</div>
</div>
<div id="footer">
<p>Contact: [email protected]</p>
</div>
</body>
</html>
PROTECTED.JSP
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-
8859-15">
<style>
img {
display: block;
margin: auto;
}
#header{
color: white;
text-align: center;
height: 400px;
font-size: 1.3em;
background-image: url("./Images/flat2.png");
background-size: cover;
}
</style>
125
<title>Autorización Correcta</title>
</head>
<body id="header">
<h1 align="center">Acaba de acceder al recurso protegido
"protected.jsp"</h1>
<img src="./Images/sign-check-icon.png" alt="Acceso Permitido"
style="align:center;width:304px;height:228px;">
</body>
</html>
ERROR.JSP
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-
8859-15">
<style>
img {
display: block;
margin: auto;
}
#header{
color: white;
text-align: center;
height: 400px;
font-size: 1.3em;
background-image: url("./Images/flat2.png");
background-size: cover;
}
</style>
<title> Autorización Fallida </title>
</head>
<body id="header">
<h1 align="center">No tiene permiso para acceder al recurso
protegido "protected.jsp"</h1>
<img src="./Images/Simple_Prohibited.png" alt="Acceso Prohibido"
style="align:center;width:304px;height:228px;">
</body>
</html>
126
STYLE.CSS
*{
margin: 0px;
font-family: sans-serif;
max-width: 100%;
left: 0;
font-weight: lighter;
}
#menu{
position: fixed;
height: 100%;
left: 0;
width: 25px;
background-image: url(../Images/dark.png);
opacity: .8;
background-size: cover;
overflow: hidden;
-webkit-transition:width,0.4s;
}
#menu:hover{
width: 300px;
}
ul{
position: relative;
margin-top: 225px;
list-style: none;
display: block;
}
li{
width: 100%;
height: 50px;
}
.servers{
padding: 16px;
padding-right: 25px;
float: left;
color: white;
font-size: 1.2em;
}
127
.text{
-webkit-transition: color,0.4s;
}
.text:hover{
color: black;
}
a{
text-decoration: none;
color: white;
}
#header{
color: white;
text-align: center;
height: 400px;
font-size: 1.3em;
background-image: url(../Images/flat2.png);
background-size: cover;
}
h1{
margin:auto;
width: 50%;
position: relative;
top: 35%;
}
.info{
width: 100%;
height: 250px;
background-color: white;
}
#acronym{
position: relative;
width: 50%;
margin:auto;
text-align: center;
font-size: 1.1em;
color: white;
top: 45%;
}
.button{
position: relative;
top: 350px;
128
text-decoration: none;
background-color: rgba(0,0,0,0.6);
border-width: 5px;
border-right: 0px;
border-left: 0px;
border-top: 0px;
font-weight: bolder;
color: white;
height: 50px;
width: 150px;
border-radius: 5px;
border-color: rgba(0,0,0,0.4);
}
.button:hover{
border-bottom: 0px;
border-color: rgba(0,0,0,0.6);
top: 355px;
height: 45px;
cursor: pointer;
}
#links{
position: relative;
top: 10px;
font-size: .9em;
opacity: 0.6;
}
#footer{
position: fixed;
width: 100%;
height: 100px;
background-color: black;
color: white;
text-align: center;
}
#footer p{
position: relative;
top: 45%;
}
129
WEB.XML
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">
<display-name>Entitlement_Sample_WebApp</display-name>
<security-constraint>
<display-name>Ejemplo de control de acceso</display-name>
<web-resource-collection>
<web-resource-name>Recurso Web Protegido</web-resource-name>
<!-- Protected URL -->
<url-pattern>/protected.jsp</url-pattern>
<!-- If you list http methods, only those methods are
protected -->
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>
<auth-constraint>
<!--
Anyone with one of the listed roles may access this area
-->
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<!-- Default login configuration uses form-based authentication -->
<login-config>
<auth-method>BASIC</auth-method>
<!--<auth-method>FORM</auth-method>-->
<realm-name>Example Form-Based Authentication Area</realm-name>
<form-login-config>
<form-login-page>/protected.jsp</form-login-page>
</form-login-config>
</login-config>
130
<!-- Security roles referenced by this web application -->
<security-role>
<description>
Rol necesario para entrar en esta aplicación web.
</description>
<role-name>everyone</role-name>
<!-- <role-name>*</role-name> -->
</security-role>
<!-- The scope in which the subject(User Name) value would be available. Legal
values are basicAuth, request-param, request-attribute, session -->
<context-param>
<param-name>subjectScope</param-name>
<param-value>basicAuth</param-value>
</context-param>
<!-- The name of the identifier by which to identify the subject -->
<context-param>
<param-name>subjectAttributeName</param-name>
<param-value>username</param-value>
</context-param>
<!-- The username to perform EntitlementService query-->
<context-param>
<param-name>userName</param-name>
<param-value>admin</param-value>
</context-param>
<!-- The password to perform EntitlementService query -->
<context-param>
<param-name>password</param-name>
<param-value>admin</param-value>
</context-param>
<!-- The URL to perform EntitlementService query-->
<context-param>
<param-name>remoteServiceUrl</param-name>
<param-value>https://localhost:9443/services/</param-value>
</context-param>
<!-- EntitlementFilter Settings -->
<filter>
<filter-name>EntitlementFilter</filter-name>
131
<filter-class>
org.wso2.carbon.identity.entitlement.filter.EntitlementFilter
</filter-class>
<!--Client Class that extends AbstractEntitlementServiceClient.
Legal values are basicAuth, soap and thrift.
Default is 'thrift'.-->
<init-param>
<param-name>client</param-name>
<param-value>basicAuth</param-value>
</init-param>
<!--
Decision caching at PEPProxy. Legal values are simple and carbon.
-->
<init-param>
<param-name>cacheType</param-name>
<param-value>simple</param-value>
</init-param>
<!--
Maximum number of cached entries. Legal values are between 0
and 10000.
-->
<init-param>
<param-name>maxCacheEntries</param-name>
<param-value>1000</param-value>
</init-param>
<!-- Time interval for which cached entry is valid. Only Works
with simple cache type. -->
<init-param>
<param-name>invalidationInterval</param-name>
<param-value>100000</param-value>
</init-param>
<!-- URL to redirect to if authorization fails -->
<init-param>
<param-name>authRedirectUrl</param-name>
<param-value>/error.jsp</param-value>
</init-param>
132
<!-- This will be used if the transport type is thrift -->
<init-param>
<param-name>thriftHost</param-name>
<param-value>localhost</param-value>
</init-param>
<!-- This will be used if the transport type is thrift. -->
<init-param>
<param-name>thriftPort</param-name>
<param-value>10500</param-value>
</init-param>
</filter>
<!-- Filter mappings used to configure URLs that need to be
authorized -->
<filter-mapping>
<filter-name>EntitlementFilter</filter-name>
<url-pattern>/protected.jsp</url-pattern>
</filter-mapping>
<!-- Mandatory mapping that needs to be present to work with PEP
cache update authorization -->
<filter-mapping>
<filter-name>EntitlementFilter</filter-name>
<url-pattern>/updateCacheAuth.do</url-pattern>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
<!-- EntitlementCacheUpdateServlet settings-->
<servlet>
<servlet-name>EntitlementCacheUpdateServlet</servlet-name>
<servlet-class>
org.wso2.carbon.identity.entitlement.filter.EntitlementCacheUpdateSe
rvlet
</servlet-class>
<!-- HTTPS port of the web container used when redirecting
request to come over https port for cache update authentication
-->
<init-param>
133
<param-name>httpsPort</param-name>
<param-value>9453</param-value>
</init-param>
<!-- Authentication mode for cache update. Legal values are
webapp and wso2is -->
<init-param>
<param-name>authentication</param-name>
<param-value>webapp</param-value>
</init-param>
<!-- Authentication page used for cache update authentication.
Legal values are default and custom -->
<init-param>
<param-name>authenticationPage</param-name>
<param-value>default</param-value>
</init-param>
<!--
Authentication page URL used for cache update
authentication. Works only with custom for authenticationPage
-->
<init-param>
<param-name>authenticationPageUrl</param-name>
<param-value>/updateCache.html</param-value>
</init-param>
</servlet>
<!-- Servlet mapping needed for cache update authentication -->
<servlet-mapping>
<servlet-name>EntitlementCacheUpdateServlet</servlet-name>
<url-pattern>/updateCache.do</url-pattern>
</servlet-mapping>
</web-app>
134
JAVASCRIPT.JS
$(document).ready(function() {
$("a").on('click', function(event) {
// Make sure this.hash has a value before overriding default behavior
if (this.hash !== "") {
// Prevent default anchor click behavior
event.preventDefault();
// Store hash
var hash = this.hash;
// Using jQuery's animate() method to add smooth page scroll
// The optional number (800) specifies the number of milliseconds
// it takes to scroll to the specified area
$('html, body').animate({
scrollTop: $(hash).offset().top
}, 800, function(){
// Add hash (#) to URL when done scrolling (default click
// behavior)
window.location.hash = hash;
});
} // End if
});
function setHeight() {
windowHeight = $(window).innerHeight();
$('#header').css('min-height', windowHeight);
$('#main').css('min-height', windowHeight);
};
setHeight();
$(window).resize(function() {
setHeight();
});
});
RECURSOS VARIOS (IMÁGENES)
* Recogidos en el CD *