sistema para el - rua.ua.es

Ángel Pérez Arroyo

1

Sistema para el seguimiento médico de pacientes

Máster Universitario en Ciberseguridad

Trabajo Fin de Máster

Autor:


Tutor/es:

Jose Luis Antón Bueso

Rafael Ignacio Álvarez Sánchez

Julio 2021


2

Índice de contenido

Resumen ............................................................................................................................................. 8

1. Introducción ............................................................................................................................... 9

1.1. ¿Qué es un sistema médico? ............................................................................................... 9

1.2. Estado del arte .................................................................................................................... 9

1.3. Ventajas de un sistema médico accesible desde Internet ................................................. 10

1.4. Objetivos del proyecto ..................................................................................................... 11

1.5. Metodología ..................................................................................................................... 12

2. Desarrollo del proyecto ............................................................................................................ 16

2.1. Elementos de seguridad requeridos para el sistema ......................................................... 16

2.2. Principios de seguridad aplicado ...................................................................................... 18

2.2.1. Perímetro de Seguridad ............................................................................................ 18

2.2.2. Superficie de Ataque ................................................................................................ 18

2.2.3. Principios de seguridad ............................................................................................ 19

2.2.4. Estrategias de defensa .............................................................................................. 25

2.3. Entorno de trabajo ............................................................................................................ 30

2.4. Tecnologías utilizadas ...................................................................................................... 34

2.4.1. Spring ....................................................................................................................... 34

2.4.2. Spring Boot .............................................................................................................. 42

2.4.3. Spring Data ............................................................................................................... 43

2.4.4. Spring Security ......................................................................................................... 45

2.4.5. Spring HATEOAS .................................................................................................... 59

2.4.6. Certificados SSL ...................................................................................................... 61

2.4.7. Claves RSA .............................................................................................................. 64

2.4.8. JWT .......................................................................................................................... 69

2.4.9. OpenID ..................................................................................................................... 73

2.4.10. OAuth 2.0 ................................................................................................................. 79

2.4.11. Docker ...................................................................................................................... 84


3

2.4.11.1. WireGuard ............................................................................................................ 89

2.4.12. SSH ........................................................................................................................ 111

2.5. Diseño de la aplicación .................................................................................................. 113

2.6. Arquitectura de la aplicación .......................................................................................... 117

3. Funcionalidades del sistema ................................................................................................... 119

3.1. Swagger .......................................................................................................................... 119

3.1.1. Swagger integrado en Spring Boot ......................................................................... 120

3.1.2. Swagger UI ............................................................................................................. 123

3.1.3. Swagger junto con el servicio desarrollado ............................................................ 126

3.2. JavaDoc .......................................................................................................................... 128

4. Resultados .............................................................................................................................. 132

4.1. Ciudadano (Citizen) ....................................................................................................... 133

4.2. Paciente (Patient)............................................................................................................ 136

4.3. Administrador de Sistemas (System Administrator) ...................................................... 139

4.4. Personal Sanitario (Health Personnel) ............................................................................ 143

4.4.1. Médico (Doctor) ..................................................................................................... 145

4.4.2. Enfermero (Nurse) .................................................................................................. 149

4.4.3. Trabajador Social (Social Worker) ......................................................................... 151

4.5. Dispositivo (Device) ...................................................................................................... 155

4.6. Historial Médico (History) ............................................................................................. 158

4.7. Registro de Acceso (Access Register)............................................................................ 161

4.8. Auditoría (Audit) ............................................................................................................ 164

4.9. Clave Pública-Privada (Private-Public Key) .................................................................. 169

5. Conclusiones .......................................................................................................................... 174

5.1. Análisis de los resultados obtenidos ............................................................................... 175

5.2. Problemas encontrados durante el desarrollo ................................................................. 177

5.3. Posibles líneas futuras .................................................................................................... 179

6. Referencias ............................................................................................................................. 180

7. Glosario .................................................................................................................................. 183


4

Índice de Ilustraciones

Imagen 1. Kanban en GitHub ........................................................................................................... 14

Imagen 3. Modelo de Seguridad Positivo ........................................................................................ 21

Imagen 4. Anotaciones Java ............................................................................................................ 36

Imagen 5. MVC ................................................................................................................................ 38

Imagen 6. Método autenticate (AuthenticationManager) - Spring Security .................................... 46

Imagen 7. AuthenticationManager - Spring Security ....................................................................... 46

Imagen 8. Estructura Spring Security .............................................................................................. 47

Imagen 9. Personalización de la autenticación ................................................................................. 48

Imagen 10. Personalización autenticación (Global) ......................................................................... 49

Imagen 11. AccessDecisionVoter .................................................................................................... 49

Imagen 12. Web Security - Servlets ................................................................................................. 51

Imagen 13. Spring Security Filters ................................................................................................... 52

Imagen 14. FilterChainProxy ........................................................................................................... 53

Imagen 15. Personalización de cadenas de filtrado .......................................................................... 54

Imagen 16. Roles de usuario - Autorización .................................................................................... 55

Imagen 17. Activación SpringSecurity ............................................................................................ 56

Imagen 18. Método de seguridad personalizado .............................................................................. 56

Imagen 19. Spring Security corriendo en distintos hilos .................................................................. 57

Imagen 20. Procesamiento de forma asíncrona - Spring Security .................................................... 58

Imagen 21. Principio HATEOS aplicado en el servicio REST ........................................................ 60

Imagen 22. HTTP vs HTTPS ........................................................................................................... 61

Imagen 23. Comunicación cifrada ................................................................................................... 62

Imagen 24. JWT - Cabecera ............................................................................................................. 69

Imagen 25. JWT- Contenido ............................................................................................................ 69

Imagen 26. JWT - Firma .................................................................................................................. 70

Imagen 27. JWT - Codificado/Decodificado ................................................................................... 70

Imagen 28. Autenticación mediante JWT ........................................................................................ 71

Imagen 29. JWT del sistema - Codificado/Decodificado ................................................................. 72

Imagen 31. Diagrama de flujo - OpenID Connect ........................................................................... 76

Imagen 32. Arquitectura OpenID ..................................................................................................... 77

Imagen 33. Flujo de OAuth2 ............................................................................................................ 80

Imagen 34. Ejemplo de petición OAuth2 ......................................................................................... 82

Imagen 35. Ejemplo petición OAuth2 con Postman ........................................................................ 83


5

Imagen 36. Contenedores tradicionales vs Docker .......................................................................... 85

Imagen 37. Conceptos de Keycloak ................................................................................................. 93

Imagen 38. Arquitectura Keycloak .................................................................................................. 94

Imagen 39. Manejo de usuarios no autenticados .............................................................................. 96

Imagen 40. Manejo de verficación de JWT ..................................................................................... 97

Imagen 41. Adaptadores para Java - Keycloak ................................................................................ 99

Imagen 43. Funcionamiento NetData ............................................................................................. 110

Imagen 44. Arquitectura del sistema .............................................................................................. 117

Imagen 45. pom.xml ...................................................................................................................... 120

Imagen 46. Configuración Swagger en Spring Boot ...................................................................... 121

Imagen 47. Interfaz Web Swagger ................................................................................................. 122

Imagen 48. Access Register - Swagger UI ..................................................................................... 123

Imagen 49. Etiqueta Java para Swagger ......................................................................................... 123

Imagen 50. Documentación petición REST utilizando Swagger ................................................... 124

Imagen 51. Documentación para Swaggeer en código fuente ....................................................... 125

Imagen 52. Uso del servicio a través de Swagger .......................................................................... 125

Imagen 53. JWT en Swagger UI .................................................................................................... 126

Imagen 54. Petición REST utilizando Swagger ............................................................................. 127

Imagen 55. Resultado petición REST en Swagger ......................................................................... 127

Imagen 56. Documentación JavaDoc en el código fuente ............................................................. 129

Imagen 57. Documentación JavaDoc - 1 ....................................................................................... 130



Imagen 60. CitizenController ......................................................................................................... 133

Imagen 61. Firma digital - Citizen Controller ................................................................................ 134

Imagen 62. Cuerpo petición - Citizen Controller ........................................................................... 134

Imagen 63. Resultado petición - Citizen Controller ....................................................................... 135

Imagen 64. PatientController ......................................................................................................... 136

Imagen 65. Firma digital - PatientController ................................................................................. 137

Imagen 66. Cuerpo petición - PatientController ............................................................................ 137

Imagen 67. Resultado petición - PatientController ........................................................................ 138

Imagen 68. SystemAdministratorController. ................................................................................. 139

Imagen 69. Firma digital - SystemAdministratorController .......................................................... 140

Imagen 70. Cuerpo petición - SystemAdministratorController ..................................................... 141

Imagen 71. Resultado petición - SystemAdministratorController ................................................. 142

Imagen 72. HealthPersonnelController .......................................................................................... 143

Imagen 73. Resultado petición - HealthPersonnelController ......................................................... 144


6

Imagen 74. DoctorController ......................................................................................................... 145

Imagen 75. Firma digital - DoctorController ................................................................................. 146

Imagen 76. Cuerpo petición - DoctorController ............................................................................ 147

Imagen 77. Resultado petición - DoctorController ........................................................................ 148

Imagen 78. NurseController ........................................................................................................... 149

Imagen 79. Resultado petición - NurseController .......................................................................... 150

Imagen 80. SocialWorkerController .............................................................................................. 151

Imagen 81. Firma digital - SocialWorkerController ...................................................................... 152

Imagen 82. Cuerpo petición - SocialWorkerController ................................................................. 152

Imagen 83. Resultado petición - SocialWorkerController ............................................................. 154

Imagen 84. DeviceController ......................................................................................................... 155

Imagen 85. Firma digital – DeviceController ................................................................................ 156

Imagen 86. Cuerpo petición - DeviceController ............................................................................ 156

Imagen 87. Resultado petición - DeviceController ........................................................................ 157

Imagen 88. HistoryController ........................................................................................................ 158

Imagen 89. Cuerpo petición - HistoryController ............................................................................ 159

Imagen 90. Resultado petición - HistoryController ....................................................................... 160

Imagen 91. AccessRegisterController ............................................................................................ 161

Imagen 92. Cuerpo petición - AccessRegistryController ............................................................... 162

Imagen 93. Resultado petición - AccessRegisterController ........................................................... 163

Imagen 94. AuditController ........................................................................................................... 164

Imagen 95. Cuerpo petición - AuditController .............................................................................. 165

Imagen 96. Resultado petición 1 - AuditController ....................................................................... 166

Imagen 97. Resultado petición 2 - AuditController ....................................................................... 167

Imagen 98. Public and Private Key Manager Encription Controller.............................................. 169

Imagen 99. Cuerpo petición 1 - Public and Private Key Manager Encription Controller .............. 170

Imagen 100. Resultado petición 1 - Public and Private Key Manager Encription Controller ....... 171

Imagen 101. Cuerpo petición 2 - Public and Private Key Manager Encription Controller ............ 172

Imagen 102. Resultado petición 2 - Public and Private Key Manager Encription Controller ....... 173


7

Agradecimientos

Quiero agradecer a mi tutor D. Jose Luis Antón Bueso, de la empresa ALTIA CONSULTORES,

S.A. por su gran apoyo, dedicación e inestimable ayuda, sin ello no habría sido posible la

realización de este proyecto. Siempre ha puesto a mi disposición algo tan preciado como es su

tiempo para ayudarme en todo lo que he ido necesitando.


8

Resumen

En la actualidad, cuando algún paciente presenta alguna patología o circunstancia personal, que le

impide acudir a su centro de salud más cercano, el personal sanitario se ve en la necesidad de

desplazarse a los correspondientes domicilios particulares. Tras la visita al paciente, el sanitario

siguiendo un protocolo preestablecido debe actualizar el historial clínico del paciente con aquella

información que considere necesaria, reflejando así, su visita y seguimiento, para el caso de que

fuera necesario.

Como no se dispone de ninguna aplicación o herramienta, que permita a los sanitarios actualizar

“in situ” el historial del paciente, éstos, al final de su jornada laboral, deben volver al centro de

salud para actualizar todos los historiales médicos de los pacientes visitados. Por este motivo, el

objetivo del presente proyecto es crear un sistema, que permita enviar y recibir datos desde

cualquier punto de la geografía española de manera segura, dada la naturaleza sensible de los datos

a tratar.

Con esto, se consigue gestionar información útil y valiosa de forma rápida y más eficiente, a la vez

que supone una mejora laboral para el personal sanitario que realiza la intervención. Y siempre en

un contexto de máxima seguridad, siendo esto último el objetivo principal del presente proyecto.

Para ello, se han utilizado diversas técnicas de seguridad con las que garantizar en todo momento la

confidencialidad, integridad y disponibilidad.

Se han implementado diversas medidas para ofrecer un sistema lo más fiable y robusto posible

utilizando algoritmos de encriptación simétricos, asimétricos, redes VPN y certificados SSL para

cada uno de los servicios utilizados.

A lo largo del presente Trabajo Final de Máster se exponen todos los elementos y tecnologías

utilizadas para implementar el servidor del sistema propuesto.


9

1. Introducción

1.1. ¿Qué es un sistema médico?

Se denomina “sistema” al conjunto de reglas o serie de principios que actúan de manera

inteligente entre sí, para formar una estructura mucho más grande. En cambio, el término

“médico” hace referencia a una organización, con una finalidad tan concreta y sensible para la

comunidad como es la gestión de nuestra salud.

Por lo tanto, el concepto sistema médico o sistema de salud hace referencia a la estructura, que

permite proporcionar asistencia sanitaria a la población de un territorio, ya sea a nivel local,

autonómico, nacional o internacional. Entre algunas de las múltiples funciones que desempeña

este tipo de sistemas son las de atender a pacientes con múltiples y muy variadas patologías.

1.2. Estado del arte

Los sistemas médicos actuales presentan varios defectos, ya que, éstos no se encuentran

adaptados o no recogen la totalidad de las necesidades sanitarias de los pacientes a los que

asiste. Entre las deficiencias que presenta se encuentra la imposibilidad de acceso,

visualización y actualización de los historiales médicos en una visita a domicilio.

Por ello, algo tan sencillo como puede ser consultar o modificar la medicación de un paciente o

bien, visualizar los resultados de una prueba, se convierte en una tarea lenta y tediosa al no

poder realizarse al momento. Esto además puede provocar errores por parte del personal a la

hora de introducir los datos de una visita, debido a que, no es lo mismo hacerlo cuando se

acaba de atender al paciente que, introducirlos al final de la jornada laboral, más aún cuando en

muchas ocasiones, por motivos de urgencia, no existe tiempo material para tomar notas.

Los sistemas actuales presentan un diseño “seguro”, pero únicamente desde el punto estático en

los que son accesibles. Pero ello resta eficacia al propio sistema en cuanto no se aborda el

acceso remoto a pesar de que existen multitud de tecnologías y técnicas con capacidad de

solventar esta necesidad de manera fiable.


10

1.3. Ventajas de un sistema médico accesible desde Internet

El sistema médico propuesto como proyecto de final de máster viene a cubrir una gran

necesidad que tienen los sanitarios encargados de atender a pacientes en sus domicilios, ya que,

en muchas ocasiones estos tienen que consultar datos sobre el seguimiento del paciente o el

resultado de alguna prueba y les es imposible, por no tener un acceso remoto.

Por ello, muchos profesionales se ven en la necesidad de preparar o mirar muy bien toda la

documentación necesaria de cada paciente antes de abandonar el centro de salud, con todo el

tiempo que esto implica. Además, añade otra variable, ya que, si el sanitario debe consultar

diversos expedientes médicos se incrementa la posibilidad de que aparezca el error humano.

Además, se le resta eficacia al sistema general en cuanto durante la visita a domicilio el

sanitario puede tener la necesidad de realizar la comprobación de datos o resultados de

pruebas, y al no tener el acceso inmediato, se debe realizar una segunda visita, por lo que, en

lugar de movilizar todos los medios para la atención de otro paciente, se ralentiza el sistema,

teniendo que repetir la asistencia.

Para el caso de que las visitas previstas por un sanitario hayan podido ir de acuerdo con lo

previsto en su agenda, al finalizar la jornada laboral el personal debe volver al centro de salud

y rellenar todos los informes de los pacientes que ha visitado, siendo este otro de los puntos

débiles de un sistema “tradicional”, ya que, el sanitario debe anotar o recordar toda la

información recopilada en sus visitas, para dejar constancia de ello en cada uno de los

correspondientes historiales médicos.

Por todo lo anteriormente descrito, se ha propuesto el sistema de seguimiento médico con el

claro objetivo de simplificar el día a día de los sanitarios, a la vez que se agilizar el sistema

disminuyendo el tiempo necesario de cada intervención domiciliaria y evitando segundas o

posteriores visitas, al mismo tiempo que, se tratan los datos médicos de los pacientes de una

manera fiable, aspecto fundamental dada la naturaleza sensible de los datos.


11

1.4. Objetivos del proyecto

En este apartado se expondrán los objetivos propuestos al inicio del proyecto que además, se

han ido completando conforme pasaban cada una de los ‘sprints’ de trabajo definidos cada dos

semanas.

Dichos objetivos son:

● Definir un sistema que tenga como máxima principal la seguridad, el control de acceso

fiable a los datos y protección de los datos sensibles.

● El sistema debe ser accesible desde cualquier lugar de la geografía española.

● Tan sólo los usuarios registrados previamente en el sistema deben poder acceder.

● Controlar los permisos de cada usuario, para verificar si las acciones solicitadas están

autorizadas o no.

● Cifrar la información sensible de los datos.

● El acceso al sistema debe realizarse a través de una VPN con uso de claves

pública/privada.

● Uso de comunicaciones SSL entre cada elemento de la arquitectura del sistema, para

asegurar en todo momento una comunicación cifrada.

● Permitir a los sanitarios acceder a información actualizada y en tiempo real sobre un

paciente.

● Permitir a los sanitarios realizar registros y modificaciones sobre datos de los sanitarios

desde cualquier lugar.

● Aprender a utilizar tecnologías muy utilizadas en entornos empresariales como Spring

Boot.

● Gestión del proceso de autenticación utilizando el protocolo OpenID

● Gestión de los permisos de usuario utilizando el protocolo OAuth2.


12

1.5. Metodología

A lo largo del presente apartado de la memoria se procederá a explicar la metodología

utilizada para llevar a cabo el proyecto, así como las principales razones por las que se ha

elegido dicha metodología.

Metodología Kanban

Motivos ● Imposibilidad para poder emplear el mismo tiempo todas las

semanas.

● Falta de experiencia previa en los campos a tratar.

● Previsiones mal realizadas por la falta de experiencia.

● Todas las tecnologías utilizadas eran nuevas para mí.

Ventajas ● Se trata de una metodología ágil y flexible.

● Resulta sencillo, eficaz e intuitivo.

Dado el tema escogido para este Trabajo Final de Máster en Ciberseguridad, que consiste

en la creación e implementación de un sistema para consultar, registrar y modificar datos

médicos de pacientes desde cualquier lugar del país, todo ello, bajo el acuerdo con la

empresa ALTIA.

Conocía de antemano que me iba a encontrar con la problemática de tener que utilizar

tecnologías de implementación totalmente nuevas, y esto necesariamente aumenta el

tiempo de desarrollo. Por lo tanto, resultaba fundamental utilizar una metodología que

fuera ágil, flexible, pero sobre todo sencilla, que permitiera ir modificando las estimaciones

realizadas en un inicio para cada una de las tareas que componen el proyecto.


13

En cuanto a la metodología, Kanban utiliza tarjetas para indicar a través de una serie de

etapas (Pendiente, En progreso y Finalizadas) las actividades pendientes de hacer, las

tareas que se encuentran en proceso y las que ya se encuentran terminadas o completadas,

así como una estimación en horas para completar cada una.

Algunas de las ventajas de Kanban son:

● Fácil organización: permite ver de una manera muy visual, rápida y sencilla, gracias a

las distintas columnas, aspectos como el flujo de trabajo actual o el número de horas

pendientes previstas hasta finalizar el proyecto.

● Distribución del trabajo: permite dividir y planificar mejor el trabajo al poder prever

fácilmente la cantidad de horas necesarias para completar la tarea. Aunque como se ha

indicado previamente, ésta podrá modificarse en cualquier momento debido a distintos

factores como puede ser la mala previsión en el cálculo de horas.

● Rendimiento: gracias al movimiento de cada una de las etiquetas, Kanban permite

también analizar si el proyecto va de acuerdo con la planificación prevista, retrasado o

más rápido de lo previsto.

Actualmente, existen multitud de herramientas gratuitas compatibles con Kanban, ya sean

online o de escritorio. Para el caso del presente proyecto, se decidió por comodidad utilizar

la incluida dentro de cualquier repositorio de GitHub, que permite ir moviendo las distintas

etiquetas a lo largo de las columnas tal y como se puede ver en la imagen inferior:


14

Imagen 1. Kanban en GitHub

En cuanto al coste de diseño y desarrollo del sistema tenemos el siguiente:

● Configuración del entorno de trabajo -> 3.5 horas

● Estudio de la documentación de Spring Boot -> 20 horas

● Realización de las guías oficiales para comprender el funcionamiento básico de

Spring Boot -> 40 horas

● Configuración básica del servidor utilizado -> 20 horas

● Aprendizaje de Docker -> 8 horas

● Configuración del contenedor MariaDB de manera apropiada -> 2.5 horas

● Configuración del servicio de VPN -> 6 horas

● Configuración del contenedor para desplegar el proyecto -> 4 horas

● Instalación y configuración del servidor Keycloak -> 10 horas

● Estudio y comprensión del funcionamiento del protocolo OpenID -> 6 horas

● Estudio y comprensión el funcionamiento del protocolo OAuth2 -> 5 horas

● Generación y configuración de certificados SSL para los servicios-> 6 horas

● Realización del diseño base del sistema -> 15 horas

● Desarrollo de proyecto

○ Gestión de Ciudadanos -> 10 horas

○ Gestión de Pacientes -> 4 horas

○ Gestión de Administradores de Sistemas -> 6.5 horas

○ Gestión de Personal Sanitario -> 5.5 horas

○ Gestión Médicos, Enfermeros y Trabajadores Sociales -> 8 horas

○ Gestión de Historiales Médicos -> 9 horas

○ Gestión de Control de Acceso -> 10 horas


15

○ Gestión Dispositivos con Acceso al sistema -> 10 horas

○ Gestión del subsistema de auditoría -> 25 horas

○ Gestión para la realización y verificación de firmas digitales -> 12 horas

● Proceso de documentación del sistema -> 30 horas

● Generación del presente documento -> 60 horas

Por lo tanto, el coste de desarrollo de la aplicación para este Trabajo Final de Máster en

Ciberseguridad ha supuesto un total de 334 horas. Si valoramos la hora a 12 euros, la

aplicación tiene un coste total de aproximadamente 4.008 euros.


16

2. Desarrollo del proyecto

2.1. Elementos de seguridad requeridos para el sistema

Dada la alta sensibilidad de los datos tratados por el sistema, resulta crucial el proporcionar

un sistema lo más fiable posible reduciendo los posibles puntos de entrada, así como

vectores de ataque a ciberdelincuentes a través de los cuales puedan acceder a los datos

médicos o personales de las personas registradas en el sistema.

Para ello, se propone un sistema en el que toda comunicación, por muy poco sensible o

interna que pueda parecer, debe ir correctamente cifrada y protegida mediante los

mecanismos más apropiados de acuerdo a la situación. Asimismo, las acciones realizadas

por los usuarios se encuentran reducidas a las mínimas indispensables. También destacar

que, cualquier información que es recibida por el servidor desarrollado en conjunto con el

framework Spring es validada antes de ser procesada, con el objetivo de evitar ataques de

inyección de código, inyección de sentencias SQL y similares. Todo ello se expondrá con

más detalle a lo largo de este segundo apartado del documento.

En concreto, para el sistema médico desarrollado se trata de un servicio que no es accesible

de manera directa desde Internet, y para el que hay que tener un dispositivo previamente

registrado, es decir, el sistema tan sólo es accesible mediante un servicio VPN

(WireGuard) para el que se requiere de una clave privada RSA de 4096 bits, que

obviamente tenga su complementaria (clave pública) registrada y habilitada en el servidor.

Por lo tanto, toda comunicación entre los dispositivos móviles de los sanitarios y el

servidor, se realiza de manera segura a través de un túnel VPN.

Los dispositivos móviles una vez acceden a la red privada donde se encuentra accesible el

servicio, tienen restringido mediante Firewall el tráfico a tan sólo dos direcciones IP,

siendo éstas las únicas indispensables con las que deben compartir tráfico, que son el

servidor de autenticación y autorización Keycloak y el servidor desarrollado bajo la

tecnología de Spring Boot.

Tras ello, los usuarios tan sólo pueden comunicarse en primera instancia con el servidor

Keycloak mediante una conexión HTTPS, ya que, para poder hacer uso del servicio REST

desarrollado, es estrictamente necesario estar debidamente autenticado contra Keycloak

para obtener un JWT válido para hacer uso del servicio REST bajo una conexión HTTPS.


17

Una vez el usuario dispone de su JWT e intente hacer uso del servicio REST, este último

procederá a verificar tres aspectos fundamentales para la seguridad del sistema que son:

verificación del JWT enviado junto a la petición HTTPS, verificación de que el terminal

solicitante está dado de alta y de que éste está habilitado para ser utilizado por el usuario

indicado en el JWT.

Por último, el servicio de base de datos MariaDB tan sólo es accesible por el servidor de

Keycloak y por el servicio REST desarrollado bajo el framework Spring.

A modo de resumen, se trata de un seguro con acceso limitado y controlado gracias al uso

de una defensa en profundidad, tanto en el sistema perimetral como una vez dentro de la

red donde se encuentra toda la infraestructura que da soporte al sistema. Este incluye

también diversas capas de seguridad para las comunicaciones, obligando a establecer

túneles VPN entre los clientes y el servidor de la aplicación, asimismo, toda comunicación

se obliga a que funcione sobre el protocolo HTTPS, añadiendo una capa adicional de

encriptación.


18

2.2. Principios de seguridad aplicado

A lo largo del presente apartado del documento se tratarán todos los principios y técnicas

de seguridad aplicados al sistema desarrollado, con el objetivo de proteger tanto a los datos

gestionados por el sistema, así como preservar que cualquier atacante pueda afectar al

correcto funcionamiento de la infraestructura levantada y requerida, para un correcto

funcionamiento del sistema.

Dada la alta importancia y sensibilidad de los datos tratados, el sistema desarrollado no es

accesible desde cualquier parte de Internet, como sí lo puede ser un servicio REST al uso,

por ejemplo Flickr. Por ello, con el objetivo de proporcionar las máximas garantías tanto a

los profesionales como a los pacientes registrados en el sistema, se han tomado una serie de

medidas que se van a detallar a lo largo de los siguientes subapartados.

2.2.1. Perímetro de Seguridad

La seguridad perimetral hace referencia a la frontera virtual que existe entre los elementos

que se quieren proteger y el resto. Para el caso particular del presente trabajo, el elemento a

proteger es el equipo servidor utilizado para levantar toda la infraestructura necesaria para

ejecutar con normalidad el sistema. Para el caso de utilizar más de un servidor la frontera

virtual estaría alrededor de los equipos que compondrían la infraestructura.

Por lo tanto, tan sólo a través del puerto reservado para el uso de WireGuard se puede

acceder al sistema. En caso de emplear cualquier otro puerto o protocolo de comunicación,

el cortafuegos integrado en el dispositivo descartará todos los paquetes entrantes.

2.2.2. Superficie de Ataque

Se podría definir como todos aquellos puntos de entrada existentes, que de ser utilizados

por un atacante comprometerían el sistema, ya sea, de manera parcial o total. Algunos

ejemplos de superficies de ataque existentes en el sistema:

● Las conexiones VPN dan acceso “físico” a la infraestructura utilizada. Se podría

llegar a atacar a la totalidad de elementos que componen la infraestructura.

https://www.flickr.com/


19

● Cualquier petición API del sistema presenta un vector de entrada, incluyendo los

parámetros proporcionados a la misma.

● Parámetros de las cabeceras utilizadas podrían llegar a comprometer el sistema si

se detectase alguna vulnerabilidad.

● La integridad del servidor Keycloak resulta un aspecto crucial para garantizar un

sistema fiable, ya que, si se comprometiera este elemento, el resto del sistema se

vería afectado de manera directa.

Dado que ningún sistema es perfecto e infalible, resulta crucial el detectar desde un inicio

todos los puntos y maneras de acceso, ya que, mediante una correcta planificación se

pueden prever la mayoría de las vulnerabilidades desde una fase muy temprana del

desarrollo. Finalizado éste y antes de su puesta en marcha en un entorno de producción, es

muy recomendable realizar un proceso de auditoría tanto interno como externo, con el

objetivo de verificar la correcta solución de todos los puntos de posibles ataques.

2.2.3. Principios de seguridad

A continuación, se exponen los principios de seguridad aplicados con el objetivo de

securizar el sistema, y hacerlo lo más fiable y robusto posible.

Seguridad en profundidad

Este principio determina que el nivel de seguridad de un

sistema se incrementa de manera sustancial, si se

aplican diversas capas de seguridad de manera

superpuesta. Es decir, no se aplica una sola medida para

proteger un componente del sistema, sino que, se

emplean varias con la finalidad de prevenir que, si una

de ellas falla, siempre exista una capa más que pueda

frenar el ataque.


20

Para el caso, de que se dispusiera de una única medida para defender una parte del

sistema, si ésta cae o falla, la totalidad del sistema podría verse comprometido.

De esta manera, se minimiza la posibilidad de que exista un punto débil o de fallo en el

sistema.

Para implementar esta capa de seguridad se han aplicado una serie de medidas, siendo

algunas de ellas las siguientes:

● El sistema tan sólo es accesible mediante VPN por el puerto y protocolo

designado.

● En el servidor utilizado se comprueba mediante una configuración de Firewall

si un paquete que entra sale o pasa (INPUT, OUTPUT, FORWARD) está

admitido o no.

● El servidor Keycloak y el servicio REST tan sólo escuchan en las direcciones

de la red física local y en las direcciones de la red virtual generada para el

servicio VPN.

● El servicio de base de datos tan sólo es accesible desde la red física local y por

el servicio REST. Usuario con mínimo privilegio aplicado.

● Se validan las credenciales y dispositivos utilizados por el personal.

● Las comunicaciones viajan cifradas en todo momento proporcionando un alto

grado de confidencialidad.

Modelo de Seguridad Positivo

El modelo positivo o también conocido como estrategia de lista blanca (whitelisting) se

trata de un modelo opuesto al tradicional negativo o de blacklisting, ya que, éste último

define todo aquello que está prohibido dando por válido cualquier petición que no

coincida con alguna condición de la lista.

En cambio, un enfoque mucho más seguro y eficaz es el modelo positivo, que hace

totalmente lo opuesto, dando por inválida o incorrecta una petición si ésta contiene

alguna parte que coincide con alguna de las reglas definidas. De esta manera, se puede

definir de forma mucho más clara, personalizada y efectiva la política a aplicar. Al

mismo tiempo, esta política también minimiza la posibilidad de introducir brechas de

seguridad, ya que, desde un inicio es mucho más restrictiva.


21

Imagen 2. Modelo de Seguridad Positivo

Por lo tanto, podríamos decir que el modelo negativo permite una introducción sencilla

de errores, mientras que, el modelo de lista blanca se esfuerza por definir todo aquello

que es correcto y válido de utilizar. Esto último es mucho más laborioso, pero más

efectivo y seguro desde cualquier punto de vista.

El modelado de seguridad positivo se ha utilizado en multitud de lugares para validar

el contenido de las peticiones, con el objetivo de determinar si estas podrían

comprometer de alguna manera el sistema o no. Por ejemplo, con cada petición que el

sistema recibe, se valida si los campos a procesar contienen caracteres especiales

como: %,/,),$... Desechando automáticamente la petición para el caso de encontrarse

algunos de ellos.

Fallo Seguro

Se trata de uno de los errores más frecuentes durante la realización de software, y es el

correcto tratamiento y manejo de los errores que se producen en una aplicación. Este es

un proceso fundamental para poder proporcionar un producto de calidad, seguro y

robusto.

Los fallos más comunes los encontramos principalmente en dos aspectos:

• Excepciones producidas al saltar una alerta durante un paso del control de

seguridad.

• Excepciones producidas por una mala programación, que no contempla todos

los casos, llegando a producir bajo determinadas circunstancias que se lance

una excepción.


22

Solucionar este tipo de situaciones es mucho más sencillo de lo que podría parecer,

debido a que, los sistemas de seguridad tan sólo deben ofrecer 3 posibles resultados:

1. Permitir la operación (Se determina que todo es correcto).

2. Rechazar la operación (Se ha detectado algo extraño o perjudicial para el

sistema).

3. Lanzamiento de una excepción (Se produce una circunstancia no controlada).

Para el caso de los resultados 2 y 3, la aplicación debe comportarse de la misma

manera, que es, desechando la petición y sin informar de manera explícita al usuario de

que ha ocurrido un error, evitando así, proporcionar más información de la

estrictamente necesaria, ya que, podría ser perjudicial en un futuro.

Mínimo Privilegio

El principio del mínimo privilegio define que los usuarios utilizados para ejecutar

programas, establecer conexiones remotas, etc, deban tener la mínima cantidad de

privilegios imprescindibles para poder ofrecer el servicio de manera correcta.

De esta forma, para el caso de descubrirse una vulnerabilidad, el atacante se topará con

unos permisos muy limitados impidiéndole en la mayoría de las circunstancias que

acometa las acciones deseadas por este.

Este principio es un concepto muy importante a tener en cuenta al desarrollar un

sistema crítico, ya que, sistemas como el desarrollado se componen de distintos

elementos, que se unen para ofrecer el servicio proporcionado. Esto también tiene un

punto negativo y es que, al mismo tiempo, esos distintos elementos pueden tener

vulnerabilidades pudiendo llegar a comprometer a otros, y en el peor de los casos la

totalidad del sistema.

Por ejemplo, para el caso particular del software desarrollado, esta técnica se ha

utilizado para la base de datos, de tal manera que, tan sólo el usuario empleado tiene

acceso a la base de datos desde la dirección IP del servidor implementado bajo el

framework Spring. Asimismo, este usuario tan sólo tiene permisos para realizar

operaciones básicas en las tablas indicadas, no pudiendo realizar otra no definida

explícitamente para dicha tabla. A modo de protección adicional y aunque el sistema


23

REST no define ninguna llamada para ello, las tablas “Audit” y “Access Register” tan

sólo permiten insertar y leer datos, no pudiendo eliminar ni modificar ningún registro

de estas, ya que, el usuario no dispone de los permisos necesarios. Así, se busca

preservar a toda costa los registros para dejar constancia de cada acontecimiento

producido en el sistema.

Importancia de la sencillez

Mantener un código fuente sencillo, claro y comprensible por cualquier desarrollador

es algo fundamental, pero en un sistema como el propuesto, esto se convierte en algo

indispensable. A este principio también se le conoce como principio KISS (Keep it

simple stupid).

Al mismo tiempo, aplicar correctamente este principio también permite aplicar o

contribuir otros principios de resiliencia como:

● Separar y aislar recursos.

● Mantener la ejecución de los distintos servicios y la información que éstos

manejan lo más alejada y oculta de los atacantes que sea posible.

● Defensa de cada capa de seguridad aplicada como si se tratara de la última.

Monitorización acciones realizadas

La monitorización continua en un sistema como el desarrollado en un entorno de

producción, resulta crucial para la correcta estabilidad de este.

Gracias a una correcta monitorización se pueden prevenir y solucionar problemas con

la suficiente antelación e impedir que estos se conviertan en problemas de gran

envergadura y puedan comprometer al sistema.

Por ello, además de la monitorización mediante la base de datos de las distintas

peticiones REST que el sistema atiende y procesa, se ha hecho uso de NetData, que es

un software especializado de monitorización de cargas de trabajo. Este software ofrece

información de manera totalmente gráfica y en tiempo real sobre cada uno de los

https://www.netdata.cloud/


24

elementos del servidor, incluida información en particular de cada uno de los

contenedores de Docker empleados.

De esta manera, se puede analizar el consumo de CPU, disco, tráfico de red, etc, por

un administrador de sistemas con un solo vistazo.

Desconfianza de la infraestructura

En la actualidad, existe multitud de hardware que, aunque en un principio pueda

parecer igual al de otras marcas o modelos, presentan pequeñas diferencias que pueden

convertir a nuestro sistema en algo totalmente inutilizable y/o con multitud de

vulnerabilidades.

Es por ello que, aunque es correcto utilizar la infraestructura como una capa de

defensa, también es cierto que, nunca se debe dejar toda la responsabilidad a dichos

elementos, ya que, en caso de que estos sean distintos o funcionen de manera

incorrecta, las consecuencias podrían ser desastrosas para nuestro sistema

Por lo tanto, es necesario asegurarse de que tanto los requisitos de funcionalidad como

los de seguridad de un sistema se pueden proporcionar también mediante software, de

esta manera, en caso de fallo en la infraestructura utilizada siempre existirá una capa

software que pueda proteger al sistema (defensa en profundidad).

Otra gran aproximación de este principio es el uso de contenedores Docker, ya que,

este servicio permite definir entornos totalmente personalizados y fácilmente

replicables en otros equipos con una pequeña cantidad de acciones. Esto permite que

tanto la distribución como configuración del sistema en nuevas infraestructuras sea

mucho más rápida y eficaz. Asimismo, también garantiza que los componentes del

sistema siempre se ejecuten de forma idéntica, eliminando la posibilidad de fallo al

utilizar otro sistema operativo, distribución, paquetes, librerías, etc, ya que, siempre

serán las mismas.


25

2.2.4. Estrategias de defensa

A continuación, se exponen algunas de las tácticas de defensa empleadas durante el

desarrollo, con el objetivo de mitigar o reducir los riesgos a los que el sistema debe hacer

frente. Como se ha venido defendiendo hasta el momento, ningún sistema informático

puede decirse que es seguro, ya que, siempre existirán brechas de seguridad o puntos

débiles, por lo que, siempre es recomendable aplicar una serie de estrategias con el objetivo

de fortalecer el sistema lo máximo posible.

Autenticación

Se trata del proceso que pretende confirmar que algo o alguien es efectivamente quien

dice ser. Este proceso se divide en dos partes o componentes que son: la parte

probadora y la parte verificadora.

En la parte probadora el usuario que desea acceder a una aplicación debe demostrarle

al sistema que es quien dice ser.

En cambio, en la parte verificadora sería el sistema quien debe confirmar y asegurar

que efectivamente el usuario que ha intentado acceder a su cuenta es el legítimo.

Para el caso del sistema desarrollado, un sanitario se autentica contra el sistema

mediante un usuario y contraseña con el objetivo de obtener un JWT, que

posteriormente le permitirá hacer uso del sistema API REST desarrollado utilizando el

framework Spring. Posteriormente, el sistema REST realizará una comprobación

adicional antes de cada petición, en la que también comprobará si el usuario

autenticado contra Keycloak, tiene el dispositivo asignado el utilizado.


26

Integridad

El principal objetivo de esta estrategia es la de prevenir y asegurar modificaciones no

autorizadas en la información tratada en un sistema.

Para prevenir este tipo de modificaciones normalmente se hacen uso de funciones

resumen, conocidas también como funciones hash o firmas digitales.

Durante el funcionamiento del sistema se hace uso de ambas técnicas para distintos

aspectos con el objetivo de asegurar con la mayor certeza posible, que la información

manejada no ha sido manipulada en ningún momento.

En el proceso de autenticación y autorización, el sistema REST desarrollado requiere

de un JWT emitido por el servidor Keycloak. Dicho token en su última parte incluye

una firma digital realizada a partir de una función “HS256”. De esta manera, el sistema

REST tan sólo tiene que verificar mediante la clave pública del servidor, que

efectivamente dicho token fue generado por él y que su contenido no ha sido alterado,

por lo que, se trata de un token válido.

Además, para cualquier petición HTTP (GET, POST, PUT o DELETE) requiere de

una firma digital que efectivamente valide la solicitud del usuario que ha realizado

dicha petición, para ello, el sistema almacena las claves públicas de los usuarios con

acceso.


27

No Repudio

Las amenazas por repudio cada vez son más frecuentes e importantes en cualquier

sistema en Internet.

Para evitar este tipo de amenazas existen 4 elementos o técnicas para abordar esta

problemática:

● Evitar transacciones fraudulentas.

● Identificación de los elementos bajo disputa.

● Investigar los elementos bajo disputa.

● Determinar y ejecutar la mejor solución.

Para solucionar este tipo de amenazas el sistema está protegido bajo 3 técnicas

principales: registro de eventos, uso de firmas digitales y marcas de tiempo seguras.

El sistema registra cualquier tipo de acción que se lleve a cabo en él,

independientemente del contenedor que haya tramitado la petición. Es decir, por

ejemplo, si el servicio de VPN recibe una nueva conexión queda registrada, así como

cualquier tipo de comunicación que un dispositivo autorizado realice. De la misma

forma, el servicio REST desarrollado registra en unas tablas designadas para ello en. la

base de datos, cualquier tipo de petición HTTPS realizada por un usuario.

Además, el sistema requiere de firmas digitales que validen y acrediten en procesos de

auditoría futuros. Todo ello se realiza mediante el uso de firmas digitales para

cualquiera de las peticiones HTTPS realizadas contra el servicio REST.

También destacar que, el sistema también registra cada uno de los eventos mediante

marcas temporales seguras, ya que, se hace uso de un proveedor NTP fiable y de

confianza (“hora.redirisi.es”). Por lo tanto, todos los relojes de cada uno de los

elementos que componen el sistema se encuentran correctamente sincronizados,

dejando información clara y válida en los registros empleados.

https://es.wikipedia.org/wiki/Network_Time_Protocol


28

Confidencialidad

Se debe tener muy en cuenta que los datos tratados por el presente sistema son

considerados como críticos, dada su alta sensibilidad. Por ello y por otros muchos

aspectos destacados en el presente documento, es muy importante que toda la

comunicación vaya correctamente cifrada y protegida.

Para solucionar la problemática de la comunicación entre los elementos que componen

el sistema, se ha hecho uso en todo momento de comunicaciones bajo el protocolo

HTTPS. De esta manera cualquier comunicación viaja de manera cifrada entre ambos

extremos.

Además, dado que las conexiones remotas (sanitarios en casa de pacientes) viajan a

través de una red totalmente insegura como es internet, es necesario añadir una capa

adicional de protección. Dicha capa se consigue al hacer pasar todo el tráfico del

sistema que viaja por Internet, a través de un túnel VPN. Esto proporciona una

seguridad que, junto con la comunicación cifrada mediante HTTPS, da lugar a un

intercambio de información con un grado de confiabilidad e integridad sumamente

elevado.

Autorización

Se trata de la acción y efecto de permitir que se lleve a cabo una acción. En definitiva,

se trata de reconocer a una persona la facultad o derecho de llevar a cabo una acción o

proceso.

Por lo tanto, aplicando esta estrategia lo que se busca es controlar qué usuario o grupo

de ellos pueden realizar ciertas acciones.

Para gestionar este proceso, los usuarios han sido clasificados en grupos para aplicar la

técnica de autorización basada en roles. Dichos roles son definidos en el servidor de

autorización del sistema, para que, de esta manera, cada vez que se emita un JWT se

defina en éste los roles o permisos a los que un usuario tiene acceso. Una vez se

incluyen estos datos en el JWT, el sistema REST ya puede comprobar antes de ejecutar

una petición HTTPS si el usuario que posee dicho token tiene los permisos necesarios

o no, para realizar dicha petición.

https://www.expressvpn.com/es/what-is-vpn/vpn-tunnel


29

En caso de que el usuario tenga los permisos suficientes, el sistema inicia el proceso

asociado a la petición realizada por el usuario. En cambio, si el usuario no está

habilitado para realizar dicha petición, simplemente se le denegará el acceso y no se

iniciará ningún proceso.


30

2.3. Entorno de trabajo

A lo largo del presente apartado se procederá a mostrar y explicar las principales herramientas

que han sido utilizadas para el desarrollo del proyecto desde un inicio, siendo éstas las

siguientes:

El software IntelliJ IDEA Ultimate ofrece un entorno de desarrollo

integrado, también conocido en el campo de la informática como IDE.

Este software ha sido desarrollado por la empresa JetBrains, y se

encuentra preparado para desarrollar software de cualquier tipo,

independientemente, del lenguaje de programación escogido (Listado de

lenguajes soportados). Para el caso particular del proyecto realizado para el presente trabajo, el

sistema se ha desarrollado utilizando el framework 1Spring Boot, para el cual el IDE dispone

de un gran soporte, ya que, incluye numerosas características que facilitan el desarrollo

utilizando dicho framework. [1]

Se trata de un software de pago, teniendo cada una de las distintas licencias que ofrece un coste

elevado. Por suerte, al ser estudiante de la Universidad de Alicante, adquirir una licencia

ampliable de un año del producto ha salido por 0 euros.

Se trata de un software que provee de todas las herramientas que un

desarrollador de Java necesita para crear cualquier tipo de aplicación o

sistema. Dicho software permite instalarse tanto en un ordenador de

manera local como ha sido el caso, o bien, instalarse en una unidad de red

para ser compartido por varios dispositivos al mismo tiempo. Para su

correcta configuración, tan sólo se deben generar tres variables de

entorno con los siguientes valores:

● JAVAPATH: ruta desde la raíz del sistema hasta la ubicación

donde se tienen los binarios el JDK2.

● CLASSPATH: debe hacer referencia a las bibliotecas o librerías

propias definidas por un usuario del software.

● PATH: se debe incluir la ruta absoluta donde se tiene el directorio

con todo el contenido del JDK descargado y descomprimido. [2]

1 Consultar en el glosario 2 Consultar en el glosario

https://es.wikipedia.org/wiki/IntelliJ_IDEA#Lenguajes_soportados

https://es.wikipedia.org/wiki/IntelliJ_IDEA#Lenguajes_soportados


31

Se trata de una herramienta para la gestión y construcción de proyectos

software para los que se utiliza como lenguaje de programación Java.

Ofrece una funcionalidad similar a Gradle o Apache Ant, pero con la

diferencia de que éste ofrece un sistema de construcción mucho más

sencillo, que se encuentra basado en XML.

Maven permite definir en un único fichero conocido como “pom.xml”,

sobre el que se aplica la técnica conocida como Project Object Model. A

través de este fichero, los proyectos Java basados en Maven permiten

construir el proyecto, al definirse en éste todas las dependencias

(directivas “dependencies” y “dependecy”), módulos (etiqueta “modules”

y “modul”), el orden de construcción del proyecto, así como cualquier

otro componente externo que se necesite durante el proceso.

Como una de sus principales ventajas presenta la gran facilidad a la hora de descargar cualquier

tipo de plugin o dependencia, ya que, éste antes de iniciar el proceso de construcción del

proyecto, inicia una sesión con el “Maven Central Repository” y descarga al equipo todos los

paquetes que sean necesarios, y tras ello, inicia el proceso de construcción. [3]

Por último, hay que destacar que Maven dispone de un ciclo de vida dividido en 9 partes,

siendo las principales las siguientes:

• Compile. Compila los ficheros con extensión “.java” para generar los ficheros

“.class”, para que puedan ser utilizados por la máquina virtual del lenguaje.

• Test. Permite ejecutar las pruebas JUnit incluidos en el proyecto, finalizando la

ejecución del proceso de construcción, si alguno falla.

• Package. Genera un fichero con extensión “.jar” siendo este resultante de la

compilación, y permitiendo su ejecución en cualquier equipo con Java instalado y

configurado correctamente.

• Install. Copia el fichero generado en la fase “Package” al repositorio local de

Maven en el equipo. Esto permite acceder al paquete en futuros desarrollos como si

de un paquete o dependencia común se tratara.

• Deploy. Copia el fichero generado en la fase “Package” a un repositorio de Maven

en la nube. Esto permite a otros desarrolladores acceder y utilizar el paquete

generado en cualquier proyecto Maven.


32

HeidiSQL es un cliente administrador de bases de datos de código abierto

que permite a los usuarios conectarse y administrar bases de datos SQL

como Microsoft SQL Server, PostgreSQL o MariaDB (Base de datos

utilizada). Gracias al uso de este cliente gráfico, se ha podido verificar de

manera fácil y sencilla el estado de las tablas de la base de datos, así como

el correcto funcionamiento de las acciones realizadas por la aplicación

servidora de este proyecto entre otras. [4]

Postman es una herramienta gratuita que busca facilitar y comprobar el

correcto funcionamiento de desarrollo de proyectos REST, SOAP y

GraphQL.

Como principal ventaja que ofrece es la de poder realizar y comprobar el

funcionamiento de manera sencilla de todo tipo de peticiones HTTP como

HTTPS sin la necesidad de implementar un cliente, abstrayendo y

reduciendo toda la problemática asociada. [5]

GitHub Desktop se trata del cliente oficial de la plataforma desarrollo

colaborativo GitHub, que permite alojar y manejar todo tipo de proyectos

software utilizando como base el control de versiones de Git. A través de

este software se han gestionado todas las versiones y mejoras añadidas al

sistema tras completar cada una de las tareas propuestas. [6]

Microsoft Visio se trata de un software especializado para el diseño de todo

tipo de diagramas, que van desde el modelado de planos a la generación de

diagramas de trabajo, pasando por la creación de diagramas UML y diseños

de bases de datos.

Para el caso del proyecto, la herramienta se ha utilizado para generar el

diagrama UML, así como para generar los diagramas de flujo que aparecen

más adelante, con el objetivo de exponer de una manera más sencilla y

visual el funcionamiento del presente proyecto realizado como trabajo de

final del máster. [7]


33

En el equipo utilizado para realizar todo el desarrollo del presente proyecto,

se ha empleado el sistema operativo Windows 10, porque permitía un

acceso rápido a todas las herramientas descritas anteriormente.

En cambio, para el servidor del proyecto, que ha sido una Raspberry Pi 4 se le

ha instalado la última versión disponible estable LTS de Ubuntu Server.

Además, sobre dicho equipo se ha instalado y configurado todo lo necesario

para el correcto funcionamiento del sistema, siempre teniendo como máxima

la seguridad.


34

2.4. Tecnologías utilizadas

A lo largo del presente apartado se procederá a describir con mayor detalle todas las

tecnologías utilizadas para llevar a cabo el proyecto siendo Spring y los proyectos

complementarios a éste, los utilizados para el desarrollo del servicio API REST que permite la

gestión de datos médicos objetivo del presente trabajo.

2.4.1. Spring

Spring es un framework de código abierto enfocado al desarrollo de

todo tipo de aplicaciones bajo la plataforma de desarrollo de Java

(JDK). Asimismo, el framework también incluye un contenedor de

inversión de control3 que es muy útil para poder obtener un mayor

grado de abstracción.

El framework fue originalmente lanzado en el 2002, pero a lo largo de los años se le han

ido añadiendo cada vez más funcionalidades, llegando a modificar gran parte de los

lenguajes utilizados, con el objetivo de adaptarse siempre a las últimas tendencias. Por ello,

el framework en la actualidad está programado utilizando Java, Kotlin y Groovy.

Además, Spring permite utilizar tanto Maven como Gradle con el objetivo de facilitar la

adopción de los entornos de trabajo ya existentes a la utilización de esta tecnología, que

como así la definen sus propios creadores, convierte a Java en un lenguaje de

programación moderno.

El framework utilizado para el desarrollo del proyecto se encuentra dividido en distintos

módulos, que pueden ser añadidos y utilizados por los desarrolladores de manera

totalmente independiente. Por lo tanto, en un proyecto se pueden determinar qué módulos

del Framework son necesarios y cuáles no. Reduciendo las dependencias del proyecto,

eliminando puntos de fallo y convirtiendo a la aplicación desarrollada en una mucho más

ligera y estable. En cuanto a los módulos del framework son muchos y variados, a

continuación, se muestra un resumen con 5 importantes módulos que construyen el

proyecto global de Spring. [8]

3 Consultar en el glosario


35

Contenedor de inversión de control

Se trata del corazón o núcleo del framework, ya que, se encarga de multitud de

acciones, entre ellas, instanciar, inicializar y conectar cualquier tipo de objeto definido

en la aplicación. Además, también se encarga de simplificar una enorme cantidad de

tareas cotidianas con el framework, lo que acelera enormemente el ritmo de trabajo, al

proporcionar un mayor nivel de abstracción.

Cualquier objeto creado y gestionado por el contenedor es llamado y etiquetado en el

programa desarrollado como “Bean” (Etiquetado en el programa como “@Bean”),

siendo esta la manera que tiene Spring de identificar, durante el proceso de

construcción del proyecto, a los objetos que deben ser creados y gestionados por él.

Comúnmente, este tipo de objetos suelen ser del tipo conocido como POJO4. Para

poder ser manejados por el módulo es necesario una serie de información que se

conoce como metadatos de configuración. Existen 3 tipos de metadatos posibles,

teniendo cada uno de ellos sus ventajas y desventajas, pudiendo incluso utilizar de

manera totalmente independiente, cualquiera de ellos:

● Etiquetas XML

● Anotaciones Java

● Objetos Java

La opción seleccionada para el desarrollo de la aplicación ha sido la segunda, ya que,

es una manera clara e intuitiva de registrar una serie de metadatos en el código fuente

del programa para que, en tiempo de ejecución y/o compilación dependiendo de la

“Bean” definida, se encuentren disponibles para un correcto proceso de construcción y

ejecución de la aplicación.



36

Las anotaciones se realizan de la siguiente manera:

Imagen 3. Anotaciones Java

La imagen superior se corresponde con un ejemplo real utilizado en la clase

“HistoryController” de la aplicación desarrollada. Las anotaciones se declaran en el

código fuente utilizando su nombre identificador precedidas del carácter “@” [9]

Ventajas del uso de anotaciones Java

Las anotaciones de Java permiten a los desarrolladores declarar en el código fuente de

la herramienta en proceso de desarrollo, la manera en la que se desea que el software se

comporte, con el simple hecho de añadir una pequeña anotación al mismo.

Desventajas del uso de anotaciones Java

Las anotaciones Las desventajas que presenta este sistema principalmente son dos:

1. Al utilizar anotaciones es necesario añadir en tiempo de ejecución una gran

cantidad de metadatos si se hace uso de diversas anotaciones simultáneas, lo

que puede producir una sobrecarga de la memoria requerida por el software.

2. Asimismo, existen pocos o nulos estándares que se encarguen de regular y

especificar el uso de este tipo de anotaciones, lo que provoca que cada

desarrollador las utilice como considere, provocando en muchas ocasiones

conflictos con el desarrollo llevado a cabo por otro programador.

Según los desarrolladores de Spring: “Spring’s flexible and comprehensive set of

extensions and third-party libraries let developers build almost any application

imaginable. At its core, Spring Framework’s Inversion of Control (IoC) and


37

Dependency Injection (DI) features provide the foundation for a wide-ranging set of

features and functionality. Whether you’re building secure, reactive, cloud-based

microservices for the web, or complex streaming data flows for the enterprise, Spring

has the tools to help.”

Programación orientada a aspectos

Se trata de un paradigma de programación, que permite una muy alta modularización y

desacoplamiento del código desarrollado, al permitir separar de una manera mucho

más clara y simple las distintas responsabilidades de una misma aplicación. Esto da

como resultado un código mucho más comprensible, fácil de aceptar nuevos cambios y

mejoras, así como permite una mayor reusabilidad de un mismo método o clase por

distintos métodos.

Además, el uso de esta programación permite también controlar de una mejor manera

el funcionamiento de la aplicación, al mantener el funcionamiento de la aplicación lo

más sencillo posible (principio KISS), reduciendo los puntos de fallo o de introducción

de brechas de seguridad, algo sumamente importante dada la importancia de los datos

procesados por el sistema, ya que, cualquier tipo de fuga de información del sistema es

considerada como crítica. [10]

Gestión de transacciones

Se trata del módulo del framework encargado de gestionar y unificar, la manera en la

que se hace uso de las distintas APIs para coordinar las distintas transacciones para los

objetos Java generados y procesados durante la ejecución de un programa desarrollado

bajo Spring.


38

Modelo-vista-controlador (MVC)

El modelo vista controlador (MVC) se trata de un

patrón básico y fundamental de la arquitectura del

software, que permite separar en tres capas muy

diferenciadas el acceso a datos (modelo), la lógica de

negocio (controlador) y la representación que se le

muestra al usuario (vista).

Los principales propósitos del modelo son la reutilización de código y la

delegación de responsabilidades. Con esto lo que se consigue es eliminar lo

conocido como “código spaguetti”.

● Modelo. Hace referencia a la representación de la información con la que el

sistema opera. En este caso se trataría de la información médica de pacientes,

gestión de sanitarios, personal administrador, etc, al tratarse de un sistema para la

gestión médica de datos de pacientes. Para el caso del software desarrollado, la

presente capa del modelo se ha denominado “Service”, siendo en dicha capa la

encargada de gestionar las consultas, actualizaciones e inserciones de datos. Según

la referencia del modelo MVC, esta capa también debería ser la encargada de

gestionar los privilegios de acceso a los datos, pero dado que se ha utilizado Spring

Security (se explica más adelante en el presente documento), que ofrece una mejor

y más fácil gestión y administración.

Por último, hay que destacar que, dado que esta capa es la que gestiona los datos,

así como las instrucciones sobre las tareas a realizar que son enviadas desde la

capa Controlador.

● Controlador. Hace referencia a la capa encargada de responder y atender los

distintos eventos que suceden en la aplicación. Para el caso particular del software

desarrollado, esta capa hace referencia a las clases de Java denominadas con la

terminación “Controller”. Dichas clases son las encargadas de atender y procesar

las distintas peticiones API REST que se incluyen en el sistema.

Por lo tanto, esta capa del patrón ha sido la encargada de enviar la información

necesaria a la capa “Service”, denominada en el modelo como “Modelo”, así como

devolver los datos producidos por la capa “Service” al usuario.

Normalmente, los datos se devolverían al cliente del sistema, para el caso

particular del proyecto desarrollado, los datos devueltos por el controlador han sido

visualizados y verificados a través de una respuesta HTTPS con un cuerpo del

Imagen 4. MVC


39

mensaje en formato JSON, que contienen la información que el cliente del sistema

tendría que utilizar para mostrarle la información de manera visual al usuario.

● Vista. Se trata de la tercera y última capa del sistema, con la que se busca la

manera adecuada de interactuar con el usuario. Esta capa normalmente hace

referencia a la interfaz de usuario (aplicación cliente), que por lo tanto requiere de

un modelo adecuado para mostrar al usuario la información devuelta por el

servidor del sistema de una manera apropiada.

Al delegar responsabilidades en determinadas clases y eliminar código repetido se

promueve la reusabilidad, mantenimiento y seguridad entre otros muchos factores,

ya que, no es lo mismo solucionar, mantener o ampliar un programa correctamente

estructurado que uno desarrollado sin utilizar un modelo apropiado. Un desarrollo

no correctamente estructurado desde un inicio es altamente propenso a incluir

numerosos errores y problemas de seguridad.

Por los motivos descritos anteriormente, son por los que se decidió utilizar dicho

modelo para el desarrollo del software desarrollado como objetivo del presente

trabajo. [11]

Testing

La realización de pruebas o testing como se conoce en inglés a esta idea, hace referencia a

la investigación tanto empírica como técnica, que proporcione una visión global sobre la

calidad de un producto software. Esta fase es la más crucial para el proceso de control de

calidad.

Existen diversos tipos de pruebas que varían en su enfoque con el objetivo de abarcar y

verificar la mayor cantidad posible de líneas de código de un producto. De esta manera, se

puede tener una mejor perspectiva sobre el correcto funcionamiento de cada una de las

secciones de un producto software.

Este tipo de pruebas se pueden dividir principalmente en dos tipos:

● Pruebas estáticas. Se trata de un tipo de prueba que se realiza sin la necesidad de

ejecutar nada de código de una aplicación. Un símil a este tipo de pruebas podría

decirse que es la revisión de documentos. Se revisa de manera visual el código

fuente de una aplicación o sección de esta, con el objetivo de seguir y analizar los

distintos flujos o caminos que contiene una herramienta.


40

● Pruebas dinámicas. Este tipo de pruebas se caracterizan a diferencia de las

anteriores en que sí requieren la ejecución de la aplicación o al menos de secciones

de esta. Gracias al uso de técnicas como las de caja negra y caja blanca, se puede

verificar el correcto funcionamiento en detalle, al poder comprobar el producto en

entornos más reales o similares a los que se va a tener que enfrentar el producto

software desarrollado.

Para elaborar los distintos casos de prueba diseñados e implementados con el objetivo de

comprobar la correcta calidad del producto desarrollado, se ha hecho uso de pruebas

unitarias. Este tipo de pruebas se encuentran englobadas dentro de las pruebas dinámicas,

ya que, ejecuta código fuente de la aplicación y, además, permiten verificar de manera muy

localizada secciones de un desarrollo. Por lo tanto, permiten hacer una serie de pruebas

muy localizadas, asegurando con mayor certeza la correcta calidad de un producto por las

distintas secciones que lo componen. [12]

A continuación, se van a describir algunas de las ventajas e inconvenientes que presentan

este tipo de pruebas:

Ventajas

1. Permiten delimitar más fácilmente los errores al encontrarse estos más acotados.

Una continua etapa de tests unitarios es muy aconsejada en desarrollos grandes o

con muchos elementos involucrados.

2. Permiten documentar el código al proporcionar ejemplos de su utilización.

3. Simplifican el proceso de integración debido a la gran eliminación de errores

descubiertos durante la fase de tests unitarios.

Desventajas

1. Las pruebas unitarias nunca afloran la totalidad de errores de un código fuente al

que se han pasado diversas pruebas.

2. Las pruebas requieren mucho tiempo para abordar la mayor cantidad de casos

posibles.

3. Las pruebas unitarias son más eficaces si se aplican junto con otras pruebas de

software.

Dada la importancia de este tipo de pruebas, el propio framework incluye un módulo

específico que simplifica esta tarea de manera notable. Además, conocedor también de lo

valiosa que es a la correcta documentación de estas pruebas, Spring incluye una etiqueta o


41

anotación de Java llamada “AutoConfigureRestDocs”, que libera a los ingenieros de

software encargados de las pruebas de documentar gran parte de las pruebas diseñadas.

Gracias a la gran potencia del framework existen diversos casos de éxito en empresas

importantes en las que Spring ha ayudado enormemente. Por ejemplo, según el líder de

transformación del área digital de la empresa “DICK’S SPORTING GOODS” destaca lo

siguiente de Spring: “We use a lot of the tools that come with the Spring framework and

reap the benefits of having a lot of the out of the box solutions, and not having to worry

about writing a ton of additional code—so that really saves us some time and energy”.

En español lo dicho por SEAN GRAHAM sería: “Usamos muchas de las herramientas que

vienen con el marco de Spring y nos beneficiamos de los beneficios de tener muchas de las

soluciones listas para usar y no tener que preocuparnos por escribir multitud de código

adicional, por lo que realmente nos ahorra algo de tiempo y energía”.


42

2.4.2. Spring Boot

El framework Spring incluye diversos módulos de desarrollo

oficiales totalmente listos para ser utilizados, siendo uno de

los más conocidos Spring Boot.

Este módulo del framework ha sido empleado desde un inicio para llevar a cabo el

desarrollo de la aplicación servidor del sistema implementado como parte de este proyecto

final de máster.

Una de las principales ventajas del uso de módulos oficiales de Spring es que reducen

drásticamente el tiempo de desarrollo de cualquier tipo de aplicación, sin repercutir en la

seguridad o en algún otro aspecto fundamental de la misma. Esto es debido a que cada

módulo es desarrollado de manera directa y revisado por la comunidad de desarrollo del

framework, permitiendo así, ofrecer a la comunidad una gran herramienta al mismo tiempo

que segura.

Por lo tanto, podríamos decir que es Spring Boot es una extensión o “suite”, que viene

preconfigurado para ejecutar aplicaciones Spring desde el primer momento y sin perder

flexibilidad.

Un caso particular de adopción de esta tecnología ha sido Netflix. Según el ingeniero de

software senior de Netflix TAYLOR WICKSELL: “Originally [Netflix's Java] libraries and

frameworks were built in-house. I'm very proud to say, as of early 2019, we've moved our

platform almost entirely over to Spring Boot.”

En español lo dicho por TAYLOR WICKSELL sería: “Originalmente, las bibliotecas y

frameworks se construían internamente. Estoy muy orgulloso de decir que, a principios de

2019, hemos trasladado nuestra plataforma casi por completo a Spring Boot.” [13]

https://spring.io/projects/spring-boot


43

2.4.3. Spring Data

Con objetivo de simplificar y poder acceder a todas las

características que ofrece Spring para acceder a datos, se ha

hecho uso del módulo Spring Data. El principal objetivo de

Spring Data (módulo de acceso a datos) es el de proporcionar a

los desarrolladores del framework un modelo sencillo y

coherente, para poder ser utilizado en cualquier tipo de

proyecto sin problemas.

En particular, el módulo está desarrollado para facilitar la conexión y acceso a cualquier

tipo de dato: bases de datos relacionales (SQL), bases de datos no relacionales (NoSQL),

marcos de reducción de mapas, así como servicios de datos basados en la nube.

Para poder ofrecer un gran producto a la comunidad, Spring Data se encuentra desarrollado

de manera totalmente desacoplada. De esta manera, existen multitud de subproyectos

desarrollados en colaboración con personal de distintas empresas, para poder ofrecer un

producto que facilite el acceso a datos independientemente de la forma de almacenamiento.

Por ejemplo, existe un subproyecto en específico desarrollado para manejar conexiones con

bases de datos MariaDB, que ha sido la base de datos utilizada.

A continuación, se muestra un listado con todos los módulos que incluye Spring Data para

manejar el acceso a multitud de maneras de almacenar información:

● Spring Data Commons: se trata de un módulo con elementos comunes al resto.

Con esto se busca desacoplar el código y favorecer su reusabilidad.

● Spring Data JDBC: permite a Spring dar soporte al repositorio de Spring Data para

JDBC.

● Spring Data JDBC (Extensión): proporciona soporte para extensiones específicas

de base de datos que la versión estándar no permite. Además, incluye soporte para

la conmutación por error de conexión rápida de Oracle RAC, soporta AQ JMS, así

como el uso de tipos de datos avanzados.

● Spring Data JPA: permite a Spring dar soporte al repositorio de Spring Data para

JPA.

https://spring.io/projects/spring-data

https://github.com/spring-projects/spring-data-commons

https://spring.io/projects/spring-data#:~:text=Spring%20Data%20module.-,Spring%20Data%20JDBC,--%20Spring%20Data%20repository

https://spring.io/projects/spring-data#:~:text=Spring%20Data%20JDBC%20Ext

https://spring.io/projects/spring-data#:~:text=advanced%20data%20types.-,Spring%20Data%20JPA,--%20Spring%20Data%20repository


44

● Spring Data KeyValue: añade soporte para el uso de repositorios basados en mapas

y SPI5, que permiten a Spring Data construir fácilmente almacenes de claves.

● Spring Data LDAP: soporta el acceso a datos en árboles LDAP.

● Spring Data MongoDB: proporciona soporte para utilizar los repositorios que

permiten manejar objetos basados en Spring para MongoDB.

● Spring Data Redis: ofrece una fácil configuración y acceso a Redis desde cualquier

aplicación desarrollada utilizando el framework Spring.

● Spring Data REST: permite exportar de manera directa los repositorios de Spring

Data como recursos Restful.

● Spring Data para Apache Cassandra: módulo específicamente diseñado para

ofrecer una fácil configuración y acceso a Apache Cassandra o aplicaciones Spring

a gran escala, con alta disponibilidad y orientadas a datos.

● Spring Data para Apache Geode: módulo específicamente diseñado para ofrecer

una fácil configuración y acceso a Apache Geode para aplicaciones Spring con alta

fiabilidad, baja latencia y orientadas a datos.

● Spring Data para Pivotal GemFire: módulo específicamente diseñado para ofrecer

una fácil configuración y acceso a Pivotal GemFire para aplicaciones basadas en

Spring con alta fiabilidad, baja latencia, alto rendimiento y orientadas a datos. [14]


https://spring.io/projects/spring-data#:~:text=support%20for%20JPA.-,Spring%20Data%20KeyValue,--%20Map%20based%20repositories

https://spring.io/projects/spring-data#:~:text=key-value%20stores.-,Spring%20Data%20LDAP,--%20Spring%20Data%20repository

https://spring.io/projects/spring-data#:~:text=for%20Spring%20LDAP.-,Spring%20Data%20MongoDB,--%20Spring%20based%2C%20object

https://spring.io/projects/spring-data#:~:text=repositories%20for%20MongoDB.-,Spring%20Data%20Redis,--%20Easy%20configuration%20and

https://spring.io/projects/spring-data-rest

https://spring.io/projects/spring-data-cassandra

https://spring.io/projects/spring-data-geode

https://spring.io/projects/spring-data-gemfire


45

2.4.4. Spring Security

Dada la problemática de la seguridad siendo ésta un

aspecto crítico en un sistema como el propuesto, se

han aplicado diversas capas de seguridad con el

objetivo de aplicar una defensa en profundidad, que

permita proteger de ciberdelincuentes los datos

personales de los pacientes, así como de los

sanitarios y administradores de sistemas registrados.

Spring Security ha sido el elemento de seguridad principal empleado en la capa software,

que al igual que los dos anteriores módulos, se trata de uno totalmente configurado y

preparado para funcionar con cualquier proyecto Spring, al disponer de total apoyo y

soporte de manera oficial.

Con este módulo se han controlado partes fundamentales de la seguridad como son:

● Las peticiones generadas por los sanitarios que se encuentren en casa de pacientes

deben provenir de un rango específico de red (Acceso al sistema mediante VPN, se

detalla más adelante).

● Los administradores del sistema tan sólo disponen de acceso desde su dirección IP

preasignada.

● No se almacenan contraseñas, al disponer de un servidor de autenticación y

autorización (Keycloak) externo.

● Se controla mediante una gestión de roles de usuario, si el usuario autenticado

dispone de los permisos necesarios para realizar dicha petición API.

Normalmente los principales problemas de seguridad de cualquier aplicación son la

autenticación (¿quién es?) y la autorización (¿está autorizado a realizar la acción?). Por ese

motivo, Spring Security está especialmente diseñado desde un inicio para separar y

personalizar como se desee tanto el proceso de autenticación como el de autorización. [15]


46

Autenticación

La principal interfaz de estrategia para la autenticación es AuthenticationManager, que solo

contiene un método:

El método anterior puede devolver 3 cosas:

1. Devolver un objeto de tipo Authentication que sirve para indicar que las

credenciales del usuario son correctas.

2. Se lanza una excepción del tipo AuthenticationException si el módulo determina

que la entrada representa un principal no válido.

3. En caso de no saber qué hacer el método devuelve nulo.

La excepción AuthenticationException es una excepción del tipo RuntimeException, que

se suele manejar tanto de manera genérica como personalizada dependiendo del propósito

de la aplicación. En un sistema backend API REST como el propuesto para el presente

proyecto final de máster, lo normal es devolver una respuesta HTTP con código 401

(Unauthorized), que ha sido la opción aplicada como se podrá comprobar en el apartado de

verificaciones.

Para llevar a cabo el proceso de autenticación, la implementación más común de

AuthenticationManager es mediante ProviderManager, permite delegar en él una serie de

instancias de AuthenticationProvider. Este último es similar a AuthenticationManager,

pero con la salvedad de que contiene un método extra que permite consultar si se admite un

tipo de autenticación en concreto o no.

Imagen 6. AuthenticationManager - Spring Security

Imagen 5. Método autenticate (AuthenticationManager) - Spring Security


47

El argumento del método llamado “supports”, se trata de un objeto de tipo “Class<?>” que

hereda de la clase Authentication. La ventaja de AuthenticationProvider es que puede

funcionar con un amplio número de tipo de autenticaciones distintas delegando

responsabilidades en la cadena de Authentication Providers. De esta manera, si un

ProviderManager no reconoce un tipo de autenticación, ésta puede pasar la responsabilidad

al siguiente ProviderManager de la cadena.

En la mayoría de las ocasiones, una aplicación tiene recursos protegidos (en el caso de la

aplicación servidor desarrollada todo requiere de autenticación). Por ese motivo, se pueden

constituir una serie de grupos con un AuthenticationManager determinado. A menudo,

cada uno de ellos es un ProviderManager y comparten un padre. Al compartir un mismo

elemento como padre, se puede ofrecer un recurso como “global”, que actúa de respaldo

para todos los proveedores. [15]

Imagen 7. Estructura Spring Security


48

Personalización de los administradores de autenticación

Con el objetivo de simplificar la implementación del proceso de autenticación, el módulo

Spring Security proporciona una serie de “ayudas” de configuración, para rápidamente

proporcionar las funciones comunes de este proceso en cualquier tipo de aplicación.

Para lograr este propósito, el asistente o ayudante más comúnmente utilizado es

AuthenticationManagerBuilder, que es ideal para configurar detalles de usuario en

memoria, JDBC o LDAP o para agregar un UserDetailsService personalizado. A

continuación, se muestra un ejemplo obtenido de una guía oficial del framework donde se

puede ver cómo se gestiona el proceso de autenticación mediante JDBC:

Imagen 8. Personalización de la autenticación

El problema con la implementación de la imagen superior es

AuthenticationManagerBuilder, porque está utilizando la etiqueta Autowired en un método

una “Bean”. Esto provoca que se construya el AuthenticationManager como global.

Para solucionar el inconveniente que supone la implementación superior, en lugar de

utilizar la etiqueta Autowired utilizamos Override sobre el método de configuración de la

clase WebSecurityConfigurerAdapter, el AuthenticationManagerBuilder se usaría sólo para

construir un AuthenticationManager de manera local, por lo que, sería un hijo del global,

mejorando así la seguridad y abstrayendo al desarrollador de la necesidad de implementar

un AuthenticationManager personalizado global. [15]


49

Imagen 9. Personalización autenticación (Global)

Autorización

Finalizado el proceso de autenticación de manera satisfactoria (credenciales enviadas por el

usuario son correctas), el siguiente paso consiste en autorizar o denegar al usuario acceder

al recurso solicitado en función de los permisos de los que disponga.

La estrategia de autorización está gestionada por AccessDecisionManager, habiendo tres

implementaciones distintas proporcionadas por el módulo, y estando cada una de ellas

delegadas en la cadena de instancias AccessDecisionVoter. Se trata de un proceso similar

al expuesto anteriormente entre ProviderManager y AuthenticationProviders.

A continuación, se exponen los tres métodos de la interfaz AccessDecisionVoter. Esta

interfaz considera un objeto del tipo Authentication y a un objeto seguro del tipo Object,

que ha sido customizado mediante la interfaz ConfigAttribute:

Imagen 10. AccessDecisionVoter


50

La interfaz superior representa cualquier recurso o cosa a la que un usuario quiere tener

acceso. En cambio, los elementos de la interfaz ConfigAttribute son bastante genéricos,

representando una personalización de un objeto de manera segura, conteniendo éste

metadatos que representan el nivel de permisos que debe disponer el usuario para acceder

al recurso solicitado.

La interfaz ConfigAttribute tan sólo define un único método que devuelve un objeto del

tipo String. Mediante dicho objeto se expresa el rol de usuario o roles de usuario que tienen

acceso a dicho recurso. Un ConfigAttribute común contiene el nombre de un rol de usuario

(como ROLE_ADMIN o ROLE_AUDIT), y a menudo, tienen formatos especiales (como el

prefijo ROLE_) o representan expresiones que necesitan ser evaluadas posteriormente.

Por último, destacar que, es muy común utilizar ConfigAttributes que pertenecen al

lenguaje de expresiones de Spring (expresiones SpEL). Por ejemplo, un ejemplo de SpEL

sería el siguiente: “isFullyAuthenticated() && hasRole('user')”. [15]


51

Web Security

Para aplicaciones web como la diseñada para el presente proyecto, Spring Security dispone

de un funcionamiento específico para este ámbito que se encuentra basado en Servlets. El

funcionamiento de Spring Security en aplicaciones web se puede entender mejor mediante

la siguiente imagen:

Imagen 11. Web Security - Servlets

Cuando el cliente de la aplicación o cualquier otro envía una petición HTTP al servidor, el

contenedor del módulo decide en tiempo de ejecución qué filtros y qué servlets se deben de

aplicar en función de la ruta solicitada y el método HTTP empleado. Como mucho un

servlet puede manejar una única solicitud, pero los filtros pueden formar una cadena como

la que se muestra en la imagen superior, ejecutándose cada uno de ellos de manera

ordenada.

De hecho, un filtro puede hacer las siguientes dos acciones:

● Puede vetar el resto de la cadena si quiere manejar la solicitud por sí mismo.

● Puede modificar la solicitud o la respuesta utilizada en los filtros descendentes y el

servlet.


52

Al ejecutarse los filtros de manera ordenada, es muy importante tener en cuenta el orden de

ejecución de los mismos, ya que, Spring Boot lo gestiona mediante dos mecanismos:

1. Etiquetas Bean del tipo Filter que pueden tener una etiqueta del tipo Order o

implementar Ordered.

2. También pueden pasar a formar parte de un FilterRegistrationBean que a su vez

tiene un orden propio al tratarse de una API independiente.

Como curiosidad destacar que, algunos filtros estándares de la cadena definen sus propias

constantes para ayudar a señalar el orden recomendado en el que deben estar. Por ejemplo,

SessionRepositoryFilter de Spring Session, tiene un DEFAULT_ORDER de

Integer.MIN_VALUE + 50, lo que indica que debe ser de los primeros de la cadena, pero

tampoco es necesario que sea el primero.

Cuando Spring Security es añadido a un proyecto basado en Spring, éste se instala con un

único filtro en la cadena siendo del tipo FilterChainProxy. En una aplicación Spring Boot,

los filtros de seguridad son del tipo “Bean”, ya que, todos ellos incluyen la etiqueta

“@Bean” en el contexto de la aplicación, lo que permite que sean instalados por defecto

cada vez que se realiza una petición HTTP a la aplicación.

Cada filtro es instalado en una posición de la cadena que viene definida por dos variables

principales:

● SecurityProperties.DEFAULT_FILTER_ORDER

● FilterRegistrationBean.REQUEST_WRAPPER_FILTER_MAX_ORDER

Imagen 12. Spring Security Filters


53

Aclarado lo anterior, también es importante mencionar que Spring Security incluye una

capa más de seguridad en el filtro de seguridad. Esta capa normalmente es instalada como

un contenedor del tipo DelegatingFilterProxy, no estando esta interfaz definida como una

“Bean” de Spring. En cambio, el proxy mencionado anteriormente sí delega en

FilterChainProxy, que es siempre una “Bean” de Spring. Esta semilla normalmente tiene

un nombre fijo o común que es “springSecurityFilterChain”. Es entonces la clase

FilterChainProxy la que contiene toda la lógica de seguridad organizada internamente

como una cadena (o cadenas) de filtros. Todos los filtros empleados por Spring Security

hacen uso de la misma API (todos implementan la interfaz Filter de la especificación de

Servlet), y todos tienen la oportunidad de vetar el resto de la cadena.

También se puede configurar Spring Security para que administre todas las cadenas de

filtrado utilizando el mismo FilterChainProxy, ya que, Spring Security contiene un listado

de cadenas de filtrado y envía la solicitud a la primera cadena que coincide con los

parámetros requeridos.

Imagen 13. FilterChainProxy

Por último, destacar que, Spring Security contempla que muchas aplicaciones basadas en

Spring Boot necesitan que ciertos recursos estáticos como las hojas de estilos (/css/**),

imágenes (/images/**), ficheros JavaScript (/js/**) o vistas de errores (/error) no necesitan

de control de seguridad, ya que, en la mayoría de las ocasiones son recursos que se quieren

ofrecer abiertamente a todo el público. Para ello, el módulo provee de una directiva

llamada “security.ignored” descrita en la configuración de la clase llamada

SecurityProperties. Mediante dicha directiva, se puede conseguir que ciertos recursos

ofrecidos por la aplicación no pasen por cadenas de filtrado.


54

Creando y personalizando cadenas de filtrado

Con el objetivo de ofrecer un mayor poder de personalización, el módulo de Spring

Security ofrece la posibilidad de crear y personalizar las cadenas de filtrado como se desee.

Para ello, tan sólo se tiene que indicar la posición en la que se debe incluir el nuevo filtro

utilizando la orden “SecurityProperties.BASIC_AUTH_ORDER”, o bien, también se puede

utilizar la función de retroceso y definir reglas con un orden anterior al común. Un ejemplo

de esto último sería el que se muestra en la siguiente imagen:

Imagen 14. Personalización de cadenas de filtrado

Gracias a la gran modularidad que ofrece este módulo de Spring, se pueden configurar de

manera distinta, reglas de acceso para adaptarse a todo tipo de aplicaciones. Por ejemplo,

habrá aplicaciones que llevarán el control de usuarios mediante Cookies, Token, Claves

asimétricas, etc, y sus procesos serán distintos dadas las necesidades del proyecto. Por lo

tanto, es necesario ofrecer un sistema que sea válido en la amplia mayoría de situaciones, y

esto se consigue gracias a la gran modularidad de Spring Security. [15]


55

Coincidencia en la solicitud para el envío de datos y Autorización

Una cadena de filtros de seguridad o de manera equivalente, un

WebSecurityConfigurerAdapter, ofrece un comprobador de solicitudes que permite

determinar si se debe procesar una solicitud HTTP o no. Para el caso de que se deba

procesar la petición, se procede a aplicar la cadena de filtros convenientes. Sin embargo, al

personalizar una cadena de filtrado, se puede obtener un mayor control sobre el proceso de

autorización al poder realizar comparaciones y verificaciones adicionales, que ofrecen una

mayor fiabilidad.

Imagen 15. Roles de usuario - Autorización

Uno de los errores más comunes al inicio de empezar a utilizar esta característica del

módulo es olvidar que las reglas se aplican de arriba a abajo y que se divide en dos

secciones. La primera parte es el comparador de solicitudes (“antMatchers”) y la segunda

es la regla que controla el acceso al recurso (“hasRole”). [15]


56

Método de Seguridad

Además de ofrecer seguridad para aplicaciones web como los servicios API REST, Spring

Security también ofrece la posibilidad de aplicar esas mismas reglas directamente a

métodos Java. De esta manera, indistintamente de si se trata de una aplicación web o no, el

módulo proporciona soporte a todo tipo de aplicaciones desarrolladas con Spring.

Habilitar esta funcionalidad es muy sencillo, simplemente añadiendo la etiqueta

“@EnableGlobalMethodSecurity(securedEnabled = true)” en la clase principal de la

aplicación, tal y como se puede ver en la imagen inferior, dicha funcionalidad debería estar

disponible.

Imagen 16. Activación SpringSecurity

En cambio, para su uso, simplemente se añadirán etiquetas como “Secure” sobre la

implementación del método desarrollado en Java, tal y como se puede ver en la imagen

inferior:

Imagen 17. Método de seguridad personalizado

En el ejemplo anterior, el framework crea una nueva “Bean”, siendo esta de tipo proxy. Por

lo tanto, antes de cada ejecución del método se comprueba que el usuario solicitante tiene

los permisos necesarios para realizar dicha acción. En caso de ser esto último afirmativo, el

método se ejecuta normalmente. Para el caso opuesto, el sistema lanzará una excepción del

tipo AccessDeniedException, sin llegar a ejecutar el método.


57

Además de la etiqueta “Secure”, existen muchas más, pero las más frecuentes son

“PreAuthorize” y “PostAuthorize”, que permiten hacer referencias a métodos definidos por

el desarrollador que se deben ejecutar antes y/o después de cada proceso de autorización.

[15]

Trabajo con hilos de ejecución

Debido a que Spring Security ofrece un mismo principio autenticado a multitud de

consumidores, este ofrece un hilo de ejecución a cada uno de ellos. De esta manera, se

puede ofrecer a cada consumidor el mismo principio sin que exista problema entre ellos al

momento de consumir la misma información. Todo ello se gestiona mediante el bloque de

construcción básico SecurityContext, que contiene un objeto del tipo Authentication.

Una de las principales ventajas de este sistema de trabajo, es que permite acceder y

manipular instancias de SecurityContext a través de métodos estáticos de la clase

SecurityContextHolder, y este a su vez modifica los datos del hilo local. [15]

A continuación, se muestra un ejemplo en el que se verifica si un usuario está autenticado

correctamente:

Imagen 18. Spring Security corriendo en distintos hilos


58

Procesamiento de métodos seguros de forma asincrónica

Para finalizar con la presente sección de la memoria referente a Spring Security, se debe

tener en cuenta la problemática subyacente de los métodos asíncronos para poder

ejecutarlos de manera segura. Dado que SecurityContext se encuentra vinculado a distintos

subprocesos (hilos de ejecución), si se desea ejecutar más métodos, siendo estos

asíncronos, es fundamental asegurarse de que el contexto (SecurityContext) se propague

por cada uno de ellos de manera correcta.

Para ayudar a los desarrolladores en esta tarea, el módulo proporciona clases específicas

como Runnable y Callable para simplificar el proceso de manera significativa. Para

propagar SecurityContext a los métodos @Async, debe proporcionar un AsyncConfigurer

y asegurarse de que el Ejecutor sea del tipo correcto. [15]

Un ejemplo práctico de todo lo anteriormente descrito es lo que se muestra en la siguiente

imagen:

Imagen 19. Procesamiento de forma asíncrona - Spring Security


59

2.4.5. Spring HATEOAS

Otro módulo muy utilizado durante todo el

desarrollo de la aplicación servidora del

proyecto ha sido Spring HATEOAS. El término

HATEOAS hace referencia a Hypermedia as

the Engine of Application State, que en español

significa hipermedia como motor del estado de

la aplicación.

HATEOAS es un componente específico empleado en diseños de arquitecturas API REST

como el desarrollado para el presente proyecto de final de máster. Aplicando esta técnica

una aplicación cliente web, puede consumir recursos ofrecidos por una API y obtener

información de manera dinámica.

Además, gracias al principio HATEOAS, una aplicación bien desarrollada bajo este

principio debería necesitar de poco o de ninguna información previa para entender cómo se

debe interactuar con el sistema.

En cambio, clientes y servidores web basados en estándares más antiguos y estáticos como

CORBA, se comunican mediante una interfaz fija o similares.

A continuación, procederemos a poner un ejemplo visual con el objetivo de que se entienda

mejor el principio HATEOAS. Cuando un cliente web que consume recursos de una API

REST, realiza una petición HTTP/S a una URL. Una vez llega la petición al servidor del

servicio, éste procesa la petición realizada por el cliente y le ofrece junto con la respuesta

de la solicitud, información adicional sobre posibles acciones futuras o interesantes en

función de la solicitud realizada.

Por ejemplo, si utilizamos como cliente REST a Postman e intentamos realizar una petición

correctamente autenticada y con los parámetros requeridos y correctos al recurso

“/patient/one” obtenemos el siguiente objeto JSON:


60

Imagen 20. Principio HATEOS aplicado en el servicio REST

Como se puede comprobar en la imagen superior, a parte de proporcionar la información

solicitada del paciente indicado, el sistema incluye al final de la respuesta un objeto JSON

llamado “_links” donde se hace referencia a la URL empleada para obtener dichos datos,

así como un enlace adicional que en este caso sirve para actualizar la información del

paciente. [16] [17]


61

2.4.6. Certificados SSL

Los certificados digitales y en particular los SSL son el corazón de la

seguridad de cualquier conexión segura en Internet. Los certificados

SSL (Secure Sockets Layer) se utilizan para establecer conexiones

cifradas entre un cliente y un servidor.

Para el caso del presente proyecto, el cliente empleado para establecer las distintas

peticiones API REST ha sido Postman, y el servidor ha sido la aplicación desarrollada

utilizando el framework Spring.

Gracias al uso de conexiones HTTPS (SSL sobre HTTP), los datos enviados entre un

cliente y servidor viajan por una red como Internet de manera totalmente confidencial,

impidiendo o dificultando considerablemente el acceso a los datos originales, para el caso

de que algún ciberdelincuente interpretara y analizara la comunicación entre ambos

extremos.

Imagen 21. HTTP vs HTTPS


62

Dada la naturaleza de los datos tratados, siendo éstos de carácter muy sensible, se ha visto

como una necesidad básica la inclusión de este tipo de certificados, con el objetivo de

anonimizar las conexiones llevadas a cabo desde cada uno de los clientes del sistema.

Todo este proceso se realiza de manera totalmente transparente para un usuario, por lo que,

no es necesario tener ningún conocimiento en el campo de la ciberseguridad para poder

establecer un canal seguro.

En cuanto al proceso de creación de un canal seguro de comunicación entre los extremos es

el siguiente:

1. En primer lugar, el servidor envía una copia de su clave pública al cliente, que para

el caso vamos a suponer que es un navegador web, aunque hay multitud de clientes

posibles.

2. A continuación, el cliente utilizado procede a crear y a enviar al servidor una clave

de cifrado para utilizar junto con un algoritmo de cifrado simétrico. Por ejemplo,

AES 256.

3. Cuando el servidor recibe el mensaje, lo descifra con su clave privada y obtiene la

clave de cifrado del algoritmo simétrico. Ahora ambos extremos comparten una

clave de sesión.

4. Llegados a este punto, tanto el cliente como el servidor de un servicio web o

similar, disponen de un canal seguro por el que compartir información, ya que, tan

sólo ellos conocen la clave de cifrado empleada para encriptar las comunicaciones.

Este proceso se repite en cada ocasión que se establece una nueva sesión contra el

servidor web.

Por lo tanto, el tiempo que se utiliza la misma clave de cifrado se considera

reducido, ya que, este tipo de conexiones no suelen perdurar en el tiempo. Para el

caso del sistema desarrollado, este tiempo nunca es superior a los 20 minutos.

Imagen 22. Comunicación cifrada


63

Para el caso particular del proyecto desarrollado, no ha sido posible utilizar un certificado

SSL válido generado mediante autoridades certificadoras como Let´s Encrypt, ya que, por

motivos de seguridad impuestos por el proveedor de acceso a Internet contratado, tanto el

puerto 80 (HTTP) como el 443 (HTTPS) se encontraban bloqueados por Firewall. Para

solucionar esta problemática se ha hecho uso de un certificado SSL autofirmado, que si

bien es igual de fiable a la hora de establecer canales de comunicación seguros, es un factor

a tener en cuenta antes de poner el sistema en producción. En caso de no modificar el

certificado SSL, la amplia mayoría de clientes web reconocerían el servicio como no

seguro o peligroso. [18] [19]


64

2.4.7. Claves RSA

Dentro del campo de la criptografía, RSA (Rivest,

Shamir y Adleman) es un sistema criptográfico de clave

pública/privada o asimétrico, que fue desarrollado en el

año 1979 dentro del Instituto Tecnológico de

Massachusetts, también conocido como MIT.

RSA es el primer algoritmo de este tipo que se publicó, además de ser el más popularmente

utilizado para multitud de propósitos, ya que, es válido tanto para firmar digitalmente como

para permitir el envío seguro de todo tipo de información.

El punto fuerte de RSA radica en la problemática de la factorización de números enteros

muy grandes, ya que, es un proceso matemático con un coste computacional sumamente

elevado, y más, con claves de 4096 bits como las utilizadas en el presente proyecto. El

funcionamiento del algoritmo se basa en el producto de dos números primos de varias

cifras, que son elegidos al azar y mantenidos en secreto.

En la actualidad estos números primos son del orden de 10300 y aumentando, ya que, a

medida que la capacidad computacional de los ordenadores va creciendo, va surgiendo la

necesidad de ampliar el tamaño de los números utilizados. Si no se utilizaran números cada

vez más grandes, aplicando técnicas como la fuerza bruta podrían empezar a convertirse en

factibles, convirtiendo esta circunstancia en una gran problemática.

Con el objetivo de dejar constancia de los datos generados o modificados por cualquier

usuario del sistema, se han generado un par de claves pública/privada RSA de 4096 bits

con las que se firma digitalmente cualquier tipo de acción que implique la inserción o

modificación de cualquier dato registrado en el sistema. De esta manera, se deja constancia

de manera fiable qué se ha realizado y quien. Este proceso es muy útil entre otros para

auditar la correcta utilización del sistema, así como para detectar anomalías o malas praxis

llevadas a cabo por el personal sanitario. [20]


65

Idea del algoritmo

El algoritmo se basa en la idea de que dos personas quieren establecer una

comunicación segura utilizando un medio inseguro como es Internet. Supongamos que

la primera persona se llama Bob, y quiere enviar un mensaje cifrado a Alice, sin que

nadie sea capaz de obtener el mensaje original.

Para ello, Alice procede a enviar a Bob una caja con un candado abierto (Clave

pública). Cuando Bob lo recibe coloca el mensaje en el interior de la caja y procede a

cerrar el candado que Alice le ha enviado. A continuación, envía la caja cerrada a

Alice. Cuando Alice recibe la caja, procede a abrir el candado con la clave que ella tan

sólo posee (Clave privada). Finalmente, Alice puede acceder al contenido del mensaje

que Bob le ha enviado. [20]

Descripción funcionamiento del algoritmo RSA

Para poder utilizar el algoritmo, en primer lugar, se necesita generar un par de

claves pública/privada con las que poder encriptar y desencriptar la información.

1. Se eligen dos números primos distintos p y q.

2. A continuación, se calcula el módulo (n), que se obtiene del producto entre

p y q (n = p * q).

3. Después, se procede a calcular φ utilizando la función de Euler (φ(n) = (p

- 1) * (q - 1)) aprovechando las dos propiedades que ofrece esta función:

a. p es primo si φ(p) = p - 1

b. m y n son primos entre sí, sólo si φ(mn) = φ(m) * φ(n)

4. El siguiente paso consiste en escoger un entero positivo e menor que φ(n),

que sea coprimo6 con φ(n).

5. El quinto paso consiste en determinar un valor d que sea el inverso de e

mod φ(n), o lo que es lo mismo, d * e mod φ(n). [21]



66

Clave pública

De acuerdo con lo expuesto en el punto anterior, una clave pública RSA, se encuentra

compuesta por los valores de n y e, siendo estos valores el módulo y el exponente de

cifrado

Clave privada

En cambio, la clave privada de un algoritmo RSA viene generada por el valor de n y d,

siendo estos valores el módulo y el exponente de descifrado. La seguridad del

algoritmo RSA se fundamenta en que esta clave se mantenga siempre en secreto. En

caso de hacerse pública la clave privada, cualquier mensaje podría ser descifrado. [21]

Proceso de cifrado

Supongamos que Alice quiere enviar un mensaje cifrado a Bob. Para ello, lo primero

que debe hacer Alice es preguntar a Bob por su clave pública. Al ser accesible y

conocida por cualquiera, tal y como su nombre indica, Bob le enviará su clave a Alice.

Una vez Alice haya recibido la clave pública de Bob, procederá a cobrar el mensaje

deseado aplicando la siguiente fórmula:

c = me (mod n)

Ahora que Alice ya dispone del mensaje cifrado mediante la clave pública de Bob,

procede a enviarle a Bob el mensaje mediante un canal inseguro como es Internet.


67

Proceso de descifrado

Llegados a este punto, supongamos que Bob ha recibido el mensaje cifrado enviado

por Alice utilizando la propia clave pública de Bob. Cuando Bob recibe el mensaje,

procede a descifrarlo utilizando su clave privada, que como su propio nombre indica,

no debe ser conocida por nadie más que Bob. [21]

Para descifrar el mensaje Bob aplica la siguiente fórmula:

m = cd (mod n)

Hay que destacar que, todo el proceso anterior funciona correctamente debido a que

como se puede ver en la siguiente ecuación, la función de descifrado es la inversa de la

de cifrado:

cd = (me)d = med (mod n)

Firma digital

Otra gran aplicación que ofrece el algoritmo asimétrico RSA es la autenticación de

mensajes, que junto con la ayuda de funciones resumen (hash), permiten realizar

firmas digitales a partir de un mensaje m. La aplicación de esta técnica se justifica

desde el momento en el que distintas transacciones se realizan a través de Internet.

Para el caso concreto del proyecto desarrollado, la firma digital se aplica para verificar

que las acciones solicitadas por un sanitario ya sean de crear una nueva entrada en el

historial, modificar algún dato de un paciente, etc, las realiza efectivamente el personal

sanitario que dice ser y no otra persona.

Para ello, suponiendo que, por ejemplo, la doctora Alice deseara firmar digitalmente la

introducción de un nuevo registro en el historial médico de un paciente se realizan los

siguientes pasos:

1. Genera un resumen de los datos que se deben registrar en el sistema, utilizando

una función hash.

2. A continuación, el cliente del sistema genera la firma digital del mensaje,

cifrado con la clave privada de Alice el hash calculado en el paso anterior.


68

3. El cliente del sistema envía todos los datos, tanto la firma digital como los

datos del paciente que deben ser registrados.

4. Cuando el servidor recibe los datos, verifica la autenticidad de estos

utilizando la clave pública de Alice que es almacenada en el servidor.

a. Si el proceso resulta satisfactorio se procesan los datos.

b. En caso de resultar incorrecto el proceso, se detiene el proceso y se

devuelve un error. [21]


69

2.4.8. JWT

JSON Web Token (JWT) es un estándar abierto (RFC 7519) que

define de una manera compacta y autocontenida, un tipo de objeto

JSON para la transmisión de información de una forma segura

entre ambos extremos de una comunicación.

Debido a que el contenido del JWT puede ser leído en todo momento durante su

transmisión, se recomienda el uso de algoritmos de cifrado como AES, que imposibiliten a

un atacante conocer la información transmitida.

En cambio, para detectar cualquier modificación del objeto JSON, la información puede

ser firmada digitalmente utilizando un secreto o bien, mediante un par de claves pública-

privada.

Un JWT está compuesto por tres partes:

● Cabecera

○ Se indica el tipo de token, que en este caso es de

tipo JWT.

○ Se indica el algoritmo empleado para la firma

(HMAC SHA256 o RSA).

● Cuerpo o contenido

○ Contiene información del usuario, así como

información adicional.

○ Suelen haber tres tipos de declaraciones:

registradas7, públicas8 y privadas9.

● Firma

○ Sirve para verificar que el mensaje no ha sido modificado durante su viaje.

Se puede hacer utilizando funciones hash o mediante una firma con clave

privada lo que garantiza el origen del mensaje.

○ Se compone de la suma del encabezado codificado más la parte del cuerpo

codificado separados por un signo de puntuación.




Imagen 23. JWT - Cabecera

Imagen 24. JWT- Contenido

https://tools.ietf.org/html/rfc7519


70

Imagen 25. JWT - Firma

Como se puede apreciar en la imagen superior, todos los componentes de un JWT van

codificados en Base64Url, por lo que, es un factor a tener en cuenta a la hora de acceder a

los datos que contiene el JWT.

Como resultado se obtienen tres cadenas con codificación Base64Url separadas entre ellas

por signos de puntuación. Esto facilita enormemente la transmisión de información a través

de protocolos como HTTP, al ser mucho más compacto que otros estándares basados en

XML.

Imagen 26. JWT - Codificado/Decodificado

Por lo tanto, las mejores situaciones para utilizar JSON Web token serían para los procesos

de autenticación y para el intercambio de información.

● Autenticación: cuando un usuario es autenticado contra el servidor, cada nueva

petición que realice incluirá en la cabecera de la petición el correspondiente JWT,

permitiendo así al usuario, acceder a los distintos servicios y recursos ofrecidos.

Además, otra gran ventaja que ofrece JWT es su utilización para desarrollar

sistemas “Single Sign On”, debido a su pequeña carga en el sistema y a la gran

capacidad para poder utilizarse fácilmente en distintos dominios.


71

● Intercambio de información: JWT también puede ser empleado para el

intercambio de información, ya que, garantiza la integridad del contenido al hacer

uso de firmas mediante funciones resumen y/o empleando sistemas de clave

pública y privada para garantizar el origen del mensaje recibido. [22]

Este sistema presenta como principal ventaja el poder garantizar el origen de las

comunicaciones, así como la notificación en caso de alteración del mensaje durante su

envío.

Esto repercute de manera directa en la seguridad del sistema, ya que, éste se convierte en

uno más robusto y fiable frente a distintos ataques

Además, su funcionamiento es muy simple y se podría resumir en el siguiente diagrama de

flujo:

Imagen 27. Autenticación mediante JWT

A continuación, se muestra un pequeño ejemplo de un JWT real utilizado en el sistema.

Dicho token ha sido generado por el servidor de autenticación y autorización utilizado

(Keycloak).

Como se puede comprobar en la imagen inferior, algunos de los parámetros más

importantes como la fecha de expiración o el usuario asociado a dicho token se encuentran

correctamente definidos de acuerdo con el estándar.

Asimismo, también se incluyen algunos campos como los roles asociados a dicho usuario o

el tipo de token empleado, siendo en este caso siempre del tipo “Bearer”.


72

A continuación, se muestra un pequeño ejemplo de un JWT real utilizado en el sistema.

Dicho token ha sido generado por el servidor de autenticación y autorización utilizado

(Keycloak).

Como se puede comprobar en la imagen inferior, algunos de los parámetros más

importantes como la fecha de expiración o el usuario asociado a dicho token se encuentran

correctamente definidos de acuerdo con el estándar.

Asimismo, también se incluyen algunos campos como los roles asociados a dicho usuario o

el tipo de token empleado, siendo en este caso siempre del tipo “Bearer”. [22]

Imagen 28. JWT del sistema - Codificado/Decodificado


73

2.4.9. OpenID

OpenID se trata de un estándar para la

identificación de usuarios en Internet de manera

descentralizada.

Al disponer de esta arquitectura, cualquier usuario que haga uso de un sistema con OpenID

puede identificarse en un sitio web a través de una URL10 o XRI11 determinada, y tras un

proceso de autenticación satisfactorio aparecerá como verificado en cualquier servidor que

haga uso del protocolo OpenID.

Un ejemplo de los servicios que hacen uso de este protocolo se puede corresponder con el

momento en el que los usuarios no se ven en la necesidad de tener que registrarse en cada

uno de ellos de manera independiente, ya que, utilizando el identificador generado por un

servidor de OpenID o también llamado proveedor de identidad (IdP), podrán acceder al

servicio de manera normal.

La parte negativa que presenta el estándar es que la seguridad de una conexión OpenID

depende principalmente de la confianza que un cliente tenga sobre un proveedor de

identidad en específico. Esto provoca que, este sistema no se haya popularizado

enormemente en Internet pese a su gran potencia, ya que, servicios con información crítica

como son los accesos a cuentas bancarias o comercio electrónico, no pueden permitir que

proveedores de identidad autentiquen de manera fraudulenta a usuarios.

Por ello, para el presente proyecto de final de máster, se ha hecho uso de un servidor de

autenticación y autorización llamado Keycloak, con el que se ha podido utilizar de manera

fiable y controlada el protocolo OpenID. Esto ha sido posible ya que, los clientes de la API

REST desarrollada utilizando el framework Spring, pueden verificar las credenciales de los

usuarios contra un proveedor de identidad seguro. Asimismo, el servicio REST

desarrollado también puede contrastar contra el servidor de Keycloak, que el JWT enviado

por el cliente para acceder a recursos protegidos es válido. [23]



https://www.keycloak.org/


74

Vocabulario referente a OpenID

1. Cliente -> Aplicación que quiere acceder a los recursos de un propietario o

propietarios.

2. Servidor de autorización -> Equipo encargado de autorizar las acciones pueden

producirse.

3. URL de redirección -> URL a la que se redirigirá al usuario cuando termine el proceso

de autenticación. La dirección dependerá de si el resultado es satisfactorio o no.

4. Token de autenticación -> Clave que permite a los clientes acceder a los recursos a los

que quiere acceder.

5. Parte confidente -> Servicio que quiere verificar la identidad de un usuario. [24]

Funcionamiento del protocolo

Ahora vamos a ver un pequeño ejemplo que permita entender de una manera más clara el

funcionamiento del protocolo. Por ejemplo, vamos a suponer que un usuario quiere acceder

al servicio UACloud, y que éste soportara el protocolo OpenID.

Cuando un miembro de la Universidad de Alicante quisiera acceder al servicio, en lugar de

introducir su correspondiente usuario y contraseña, en el mismo formulario habría un botón

o similar que permitiera acceder utilizando OpenID Connect, de la misma manera que hay

uno para acceder por Certificado digital.


75

Una vez seleccionado el método de autenticación, si por ejemplo se quiere acceder

utilizando el proveedor de identidad “ciberseguridad-openid.org”, el usuario simplemente

introduciría lo siguiente: usuario.ciberseguridad-openid.org. Llegados a este punto el

servicio de UACloud utilizando el correspondiente cliente de OpenID junto con la URL

adecuada, solicitaría al servidor indicado por el usuario los datos requeridos para que el

usuario pueda ser autenticado. Si el proceso puede ser completado correctamente, el

usuario accedería al servicio de UACloud normalmente. [23]


76

Lo anteriormente indicado puede verse desglosado mediante el siguiente diagrama de flujo:

Imagen 29. Diagrama de flujo - OpenID Connect

Modos de funcionamiento del protocolo

El protocolo OpenID Connect ofrece dos mecanismos distintos para su utilización, con el

objetivo de que la parte confidente pueda comunicarse correctamente con el proveedor de

identidad seleccionado por el usuario.

1. checkid_immediate -> se trata de un sistema enfocado a la identificación

automática. De esta manera el usuario no es consciente de todo el proceso que se

está llevando internamente, ya que, toda la comunicación necesaria entre los

servidores (proveedor de identidad y servidor del servicio) se realiza como una

tarea más.

2. checkid_setup -> se trata de la opción más común que se utiliza en aplicaciones

Web. En esta opción a diferencia de la anterior, el usuario es redirigido para que se

autentique en el servicio IdP. Finalizado el proceso de autenticación, éste es

redirigido al servicio al que quería acceder.


77

OpenID 2.0

La versión 2 del protocolo funciona de una manera similar a OpenID Connect, pero con la

principal salvedad de que el uso de la API es mucho más sencillo, intuitivo y utilizable

para multitud de aplicaciones de manera nativa.

Además, gracias al uso de la segunda versión del protocolo se pueden acceder a mejores y

más robustos sistemas de verificación y encriptado, que la primera versión de la API no

incluye.

Finalmente, destacar que, OpenID Connect incluye e integra capacidades de OAuth 2.0 de

manera totalmente integrada y nativa, ofreciendo mayores funcionalidades y posibilidades

con la que desarrollar multitud de sistemas bajo este estándar. [23]

Imagen 30. Arquitectura OpenID


78

Control sobre OpenID

Una de las principales garantías para el uso de OpenID es que es OpenSource. Esta

tecnología fue desarrollada durante el 2005 por la comunidad de desarrolladores, con el

objetivo de dar una solución fiable e integrable en multitud de sistemas, que permitiera

solucionar la problemática del proceso de autenticación.

Al tratarse de una tecnología totalmente gratuita, accesible y totalmente descentralizada,

cualquier persona se puede convertir en “OpenID Provider”, sin la necesidad de registrarse

y añadir funcionalidades al protocolo, mejorando aún más las características de este. [23]


79

2.4.10. OAuth 2.0

El protocolo OAuth 2.0 es el estándar de la industria en lo

referente al proceso de autorización. Este estándar busca en todo

momento simplificar la tarea de desarrollo de cualquier tipo de

sistema, ya que, en la actualidad muchas aplicaciones necesitan

realizar las mismas o similares tareas de gestión y autorización de

acceso a datos.

Una de las principales ventajas de este protocolo es que incluye soporte para todo tipo de

aplicaciones: móviles, web, escritorio, etc, por lo que, su aplicación es prácticamente

infinita. Esto es debido a que su gran modularidad que le permite adaptarse a multitud de

entornos que, junto con su gran funcionamiento, le ha hecho convertirse en un referente

claro para ser utilizado en prácticamente cualquier aplicación.

Asimismo, todas sus especificaciones y extensiones se encuentran en continuo desarrollo

dentro del IETF OAuth Working Group.

El protocolo OAuth 2.0 es cierto que se puede utilizar en muchos ámbitos totalmente

distintos, pero uno de los más populares es la gestión de los procesos de autorización para

servicios API como el desarrollado para el presente proyecto. [25]

2.4.10.1. Vocabulario referente a OAuth 2.0

1. Propietario del recurso -> El dueño de los recursos que son accesibles utilizando el

sistema, y que da su autorización para que dichos recursos puedan ser consumidos

por otros usuarios.

2. Servidor del recurso -> Equipo encargado de almacenar y proporcionar a los

usuarios los recursos requeridos.

3. Aplicación cliente -> Software que simplifica a un usuario el acceso a los datos, así

como el encargado de acceder a los datos de la cuenta del usuario, para lo que

suele solicitar permiso.

4. Permisos del usuario -> Permisos que un usuario dispone En función de sus

permisos podrá tener disponibles o no determinados recursos.

https://www.ietf.org/mailman/listinfo/oauth


80

5. Servidor de autenticación -> Se trata del equipo encargado de gestionar las

distintas peticiones que le llegan, para autorizar o denegar el acceso al recurso

solicitado por el usuario.

2.4.10.2. Flujo de OAuth2

El flujo llevado a cabo por un sistema que hace uso del protocolo OAuth2 sería el que se

muestra en la siguiente imagen:

Imagen 31. Flujo de OAuth2

Para el caso del sistema de gestión médica desarrollado, los recursos son globales al

desearse que la información médica de un paciente pueda ser consultada por varios

sanitarios. Por lo tanto, el proceso de autorización se gestiona en función del “ROLE” del

usuario, es decir, si un usuario determinado dispone de unos permisos mínimos, se le

permite el acceso al recurso API y en caso contrario se le deniega el acceso.

Por lo tanto, para el caso concreto del sistema diseñado, el usuario en primer lugar debe

autenticarse contra el servidor Keycloak, ya que, cualquier petición en el sistema debe ir

correctamente autenticada (proceso necesario para obtener el JWT). A continuación, el

servidor de autorización (Keycloak) determina si el usuario dispone de los permisos

necesarios para que dicho usuario pueda acceder al recurso o no. En caso afirmativo, el

servidor de recursos procede a procesar su petición. [26]


81

Tipos de concesión (Grant types)

Dentro del estándar de autorización OAuth 2.0 se proponen distintos mecanismos para

llevar a cabo el proceso de concesión de acceso a datos. En definitiva, los tipos de

concesiones disponibles no son más que maneras mediante las que se puede obtener un

token de acceso válido para una aplicación.

Cada uno de los tipos presenta sus ventajas e inconvenientes por lo que es recomendable

estudiar detenidamente cada uno de ellos, y escoger el que mejor se adapte al sistema en

cuestión.

A continuación, vamos a mencionar algunos de los tipos propuestos dentro del estándar:

● Credenciales de cliente

● Implícito

● Código de autorización

● Código de autorización con PKCE

● Credenciales de contraseña

Credenciales de contraseña

El tipo de concesión por contraseña o como también se le conoce “Resource Owner

Password Credentials”, se trata de un flujo de autorización que normalmente es sólo

recomendable para entornos seguros como el propuesto, ya que, para que su aplicación se

considere fiable debe existir una relación de confianza entre todos los componentes del

sistema.

Además, la concesión por contraseña se trata de una de las más simples que el protocolo

define, y para la que tan sólo es necesario llevar a cabo un paso. Normalmente, para

facilitar al usuario la utilización de un sistema con concesión por contraseña, se incluye un

formulario donde se recoge el usuario y contraseña de manera tradicional y se validan en

el servidor. Tras una correcta validación, se devuelve un token de acceso, que en esta

ocasión como se ha visto anteriormente es del tipo JWT.

Un ejemplo de petición HTTP que se debe realizar para aplicar correctamente este tipo de

concesión en particular es el que se muestra en la imagen inferior.


82

Imagen 32. Ejemplo de petición OAuth2

Como se puede ver en la imagen superior, es necesario incluir los siguientes parámetros o

información:

1. URL sobre la que se deben validar las credenciales del usuario.

2. Dirección del servidor que debe validar las credenciales.

3. Tipo de contenido de la petición.

4. Tipo de concesión de contraseñas => password para este caso particular.

5. Nombre de usuario.

6. Contraseña del usuario.

7. Identificador de cliente.

A continuación, se muestra una configuración real utilizada en el software Postman con el

objetivo de que el servidor de autenticación y autorización devuelva un JWT válido para

ser utilizado en el servicio REST del sistema desarrollado. [27]


83

Imagen 33. Ejemplo petición OAuth2 con Postman

Con la configuración anterior, iniciado el proceso de autenticación, Keycloak, devuelve a

Postman un token JWT que es válido para ser utilizado en el sistema. Este token tiene un

formato como el mostrado anteriormente en el apartado referente a JWT.


84

2.4.11. Docker

Dados los recursos disponibles para montar un servidor físico, se ha

hecho uso de una Raspberry Pi 4 sobre la que se ha levantado la

totalidad del sistema desarrollado para el presente proyecto de final

de máster.

Como los recursos del equipo utilizado son bastante limitados, existe la necesidad de

optimizar los procesos ejecutados sobre el mismo lo máximo posible, con el fin de poder

disponer de la mejor experiencia a los usuarios del sistema, al mismo tiempo que, se

garantiza que la estabilidad del sistema con un grupo reducido de usuarios utilizando el

sistema al mismo tiempo.

Además, con el objetivo de aislar los distintos elementos que componen el sistema lo

máximo posible, minimizando el rango de ataque de un ciberdelincuente en caso de

detectarse alguna vulnerabilidad en el sistema, se ha hecho uso de la tecnología Docker.

Una de las principales ventajas de Docker es que, permite conseguir una mayor eficiencia y

rendimiento que ejecutando máquinas virtuales tradicionales, mediante softwares como

VirtualBox o VMWare.

Docker es un software enfocado a las tecnologías de la información, que permite crear todo

tipo de contenedores basados en Linux. Por ese motivo es muy fácil encontrar

contenedores de Docker utilizando Ubuntu, Debian, Centos, Alpine, etc. Así mismo,

Docker dispone de una gran comunidad OpenSource a sus espaldas que está mejorando de

manera continua todo el ecosistema de Docker, con el objetivo de poder ofrecer a los

usuarios de manera totalmente gratuita un mejor producto.

Este software se encuentra gestionado por la empresa Docker Inc., que colabora

activamente con la comunidad, con el objetivo de poder ofrecer un producto mejor y más

seguro, al mismo tiempo que también comparte los avances logrados con el resto de la

comunidad.

https://www.docker.com/


85

Funcionamiento de Docker

El motivo principal por el que Docker tan sólo permite ejecutar contenedores basados en

Linux, es porque utiliza funciones propias de este sistema operativo. Algunas de ellas son

“Cgroups” y “namespaces”, que permiten separar los procesos pudiendo ejecutarse de

manera totalmente aislada del resto.

Por ello, el propósito que se busca conseguir mediante Docker es conseguir justo, esta

independencia entre distintos procesos, pudiendo ejecutar programas, aplicaciones, etc, por

separado, con el objetivo de hacer un mejor uso de la infraestructura disponible, así como,

disponer de una mejor seguridad al disponer de sistemas separados y aislados.

Diferencia con contenedores Linux tradicionales

Los contenedores tradicionales de Linux se encuentran basados en la tecnología LXC, que

hace unos años era útil como medio de virtualización “ligera”, pero que presentaba

diversos inconvenientes, que dificultan su utilización tanto a usuarios como

desarrolladores.

Mediante el uso de Docker no sólo se proporciona a los usuarios y desarrolladores la

capacidad de ejecutar contenedores, sino que también se simplifica de forma considerable

el proceso de creación y diseño, así como el envío y compartición de las imágenes de los

contenedores. Por último, hay que destacar que, Docker también permite hacer uso de un

gestor de versiones con el que se puede manejar de una mejor manera las distintas mejores

de una imagen.

Imagen 34. Contenedores tradicionales vs Docker


86

Finalmente, destacar que, los contenedores Linux tradicionales usan un sistema “init” que

permite gestionar varios procesos, es decir, las aplicaciones completas se ejecutan como

una sola. En cambio, con Docker las aplicaciones se pueden separar como se desee.

Por ejemplo, para el sistema desarrollado se ha hecho uso de 4 contenedores Docker,

estando cada uno de ellos encargado de diferentes aspectos, permitiendo delegar ciertas

responsabilidades a contenedores específicos. Así la aplicación obtiene un mayor grado de

modularidad y aislamiento. [28]

Ventajas

Como se ha visto anteriormente, el uso de Docker como tecnología de “contenerización”

presenta múltiples ventajas que se van a resumir a lo largo del siguiente subapartado.

A grandes rasgos, Docker tiene cuatro principales ventajas que son:

1. Modularidad

2. Control de versiones

3. Restauración

4. Implementación rápida

Modularidad

El enfoque propuesto por Docker permite separar una aplicación en muchos elementos o

componentes independientes, pudiendo personalizarlos y adaptarlos para funcionar como

se desee. Para el caso del proyecto desarrollado, el sistema está dividido en 4 contenedores

de Docker, encargados de las siguientes tareas:

1. Gestionar conexiones VPN.

2. Gestionar peticiones HTTPS.

3. Gestionar conexiones a la base de datos.

4. Gestionar los procesos de autenticación y autorización.

Además, gracias al enfoque utilizado que se encuentra basado en una arquitectura de

microservicios, se pueden compartir distintos procesos de un mismo contenedor entre

distintas aplicaciones, de la misma forma que funciona la arquitectura orientada al servicio


87

(SOA). Por ejemplo, un mismo motor de base de datos puede ser utilizado por distintas

aplicaciones indistintamente.

Control de versiones

Una imagen de un contenedor Docker se encuentra compuesta por una serie de capas, que

se van añadiendo una encima de la otra. Cuando todas estas capas se combinan dan lugar a

lo que se conoce como una imagen. Cada vez que un usuario realiza la ejecución de un

comando, sea del tipo que sea, se añade una nueva capa, dando lugar a una nueva versión

de la imagen.

Para solucionar el problema derivado del tiempo empleado para generar una nueva versión

de una imagen, Docker reutiliza las capas anteriores que componen el contenedor. De esta

manera, el tiempo necesario para construir una nueva imagen se reduce sustancialmente.

Restauración

Una de las grandes ventajas que ofrece esta tecnología y que la mayoría de sus usuarios

desconoce, es la simplicidad a la hora de volver a un punto anterior o proceso de

restauración. Al estar compuesta una imagen por distintas capas, constituyendo cada una de

ellas una nueva imagen, se pueden eliminar las capas deseadas hasta volver al momento

deseado.

Implementación rápida

Hace unos años el tiempo necesario para configurar adecuadamente un entorno de

desarrollo o producción, podía ser una tarea compleja y larga en el tiempo. Esto se puede

solucionar fácilmente utilizando Docker, ya que, el tiempo necesario para disponer de una

base de datos se puede reducir, literalmente, a unos pocos segundos.


88

Además, si se necesita configurar un contenedor de una manera muy concreta o particular

para conseguir que una aplicación funcione correctamente, gracias al sistema de

compartición de imágenes que integra esta tecnología, se puede compartir una imagen con

otros usuarios y que éstos, automáticamente, dispongan del mismo entorno para ejecutar la

aplicación.

Por último, destacar que, gracias a la alta velocidad con la que los contenedores se pueden

crear o destruir, se pueden levantar y eliminar entornos a una velocidad muy elevada. [29]


89

2.4.11.1. WireGuard

Con el fin de gestionar las distintas conexiones VPN, que

permitirá el acceso al sistema por los sanitarios que se desplazan al

domicilio de pacientes con la imposibilidad de acudir al hospital o

centro de salud más cercano, se ha generado un contenedor de

Docker que hace uso de una imagen con el software WireGuard.

WireGuard es un servicio que permite definir un servidor de conexiones VPN. Una de las

grandes ventajas que ofrece esta tecnología es la capacidad de poder ofrecer una VPN

simple, rápida y moderna, pero siempre teniendo la seguridad como una máxima, ya que,

se hace uso de funciones criptográficas de última generación.

El principal objetivo de WireGuard es el de poder ofrecer a sus usuarios un rendimiento

global mucho mejor que el que ofrecen tecnologías alternativas como IPsec o OpenVPN.

El servicio WireGuard está diseñado como una VPN de propósito general tanto en equipos

ligeros y compactos, como en servidores con mucha mayor capacidad, que para equipos

como una Raspberry es algo fundamental para un correcto funcionamiento del resto de los

procesos. Tras verificar su correcto funcionamiento, se ha podido comprobar que es cierto,

ya que, el uso de CPU con diversos usuarios haciendo uso de conexiones VPN no ha

aumentado significativamente.

Otro factor a tener en cuenta es que dispone de clientes oficiales para prácticamente

cualquier plataforma: Windows, macOS, Linux, iOS y Android.

El servicio, actualmente, se encuentra en un proceso de desarrollo intenso, pero ya se

puede utilizar con total normalidad, al mismo tiempo que, también se puede considerar

como una de las mejores opciones para un servidor de conexiones VPN.

https://www.wireguard.com/


90

Simplicidad

WireGuard pretende ser una opción fácil tanto a nivel de configuración como de

utilización, llegando al nivel de servicios más cotidianos como SSH del que se hablará más

adelante. Para iniciar una conexión VPN, se hace uso de un intercambio de claves RSA, al

igual que como se hace cuando se accede mediante SSH,, siendo un proceso totalmente

transparente para cualquier usuario.

En resumen, WireGuard presenta una interfaz extremadamente simple, pero

extremadamente potente. [30]

Criptográficamente sólido

WireGuard hace uso de criptografía de última generación al utilizar funciones como Noise,

Curve 25519, ChaCha20, Poly1305, BLAKE2, SipHash24 o HKDF, que convierten a

WireGuard en un servicio fiable. Además, el software es continuamente revisado por

criptógrafos con el objetivo de garantizar la integridad y confidencialidad de los datos.

Superficie de ataque mínima

WireGuard ha sido diseñado desde el principio teniendo como un aspecto fundamental la

simplicidad, tanto para la implementación como para el uso de los usuarios. Por ello, el

software está diseñado para ser implementado en la menor cantidad de líneas de código

posibles, lo que simplifica notablemente los procesos de auditoría por los que pasa tras

cada nueva versión.

Así, en comparación con sus principales competidores como OpenVPN, OpenSSL o Swan,

WireGuard requiere un proceso de auditoría mucho más rápido y sencillo, a diferencia de

sus competidores que tienen que analizar gigantescas bases de datos y un número muy

superior de líneas de código, algo que, incluso para un grupo de expertos resulta una tarea

abrumadora.


91

Alto rendimiento

Los principales motivos por los que WireGuard es mucho más rápido que sus competidores

son dos principalmente: el uso de funciones criptográficas optimizadas y su correcta

integración dentro del kernel de Linux, lo que tiene como relación directa un gran aumento

del rendimiento.

Todo ello provoca que, se puedan disponer de redes seguras y de muy alta velocidad.


92

2.4.11.2. Keycloak

Keycloak es un servidor de autenticación y autorización

desarrollado principalmente en Java por la compañía Red Hat

desde el año 2013, siempre bajo la licencia de Apache. Su

utilización no comenzó a popularizarse hasta el año 2015,

convirtiéndose en un gran producto que permite a los

desarrolladores de todo tipo de aplicaciones, abstraerse de la

problemática de desarrollar e implementar los procesos de

autenticación y autorización necesarios.

Desde hace años, Keycloak dispone de una nueva versión cada 6 semanas, ya que, dispone

de un gran desarrollo tanto de mantenimiento como de implementación de nuevas

funcionalidades, que convierten a Keycloak en una gran opción siendo esta muy fiable.

El servidor de autenticación y autorización utilizado en el proyecto dispone de infinitas

características, pero a continuación se muestran las más relevantes:

● Facilita el desarrollo de aplicaciones “Single Sign-on” y “Single Sign-out”.

● Hace uso de protocolos estándares como: OAuth 2.0, OIDC 1 .0, SAML 2.0 y

OpenID Connect.

● Realiza un proceso flexible de autenticación y autorización.

● Permite aplicar varios factores de autenticación como contraseñas de un solo uso o

verificaciones por doble factor (Google Authenticator, Correo electrónico...).

● También es compatible con la autenticación social, teniendo soporte para los

principales proveedores: Google, Facebook, Twitter….

● Es compatible con Active Directory y versiones similares de código abierto, por lo

que, puede acceder y utilizar información ya existente en árboles LDAP de las

organizaciones. [31]


93

Conceptos principales

A continuación, vamos a tratar los conceptos principales asociados a un servidor Keycloak,

que permitirán entender de una mejor manera futuras explicaciones.

Imagen 35. Conceptos de Keycloak

A. Realm: se trata de la generalización de todo aquello que es necesario para realizar

un proceso de autenticación y autorización para una aplicación o conjunto de ellas

(Single-Sign-On).

B. User -> Listado de usuarios que están registrados y que disponen de acceso a la

aplicación.

C. Client -> Aplicación que va a utilizar Keyclock para realizar los procesos de

autenticación y autorización.

D. Roles -> Roles o grupos que van a poder tener los usuarios. Por ejemplo, para el

presente proyecto existen roles para médicos, enfermeros, trabajadores sociales y

administradores de sistemas.

E. (UI) Themes -> Aspecto visual y configuraciones ofrecidas por el servidor a los

distintos usuarios y clientes, que hacen uso de éste.

F. Identity Provider -> Encargado de obtener la identidad del usuario a partir de otro

proveedor.

G. Keys -> Listado de claves que pueden ser necesarios por Keyclock y sus clientes

asociados para establecer una conexión más fiable.

H. User Federation -> Permite conectarse con servidores Kerberos o LDAP.


94

Arquitectura del servidor

Como se puede ver en la imagen inferior, un servidor Keycloak está altamente

modularizado, permitiendo una gran introducción de mejoras, así como la solución de

problemas o vulnerabilidades encontradas.

Imagen 36. Arquitectura Keycloak

Debido a su diseño y arquitectura, Keycloak dispone de una serie de módulos

especializados cada uno de ellos en determinadas tareas. Por lo tanto, dichos módulos

pueden ser activados o no, dependiendo de las circunstancias de los distintos reinos

definidos.

Para el caso del proyecto desarrollado, en el reino (“realm”) definido en Keycloak se han

activado y utilizado los siguientes módulos:

● El módulo Realm fue el primero que se utilizó, ya que, tras la instalación del

servidor, se procedió a aplicar diversas técnicas de securización, con el objetivo de

proteger al servidor de ciberdelincuentes o ataques contra el mismo. Tras ello, el

módulo tan sólo se ha utilizado para acceder a través de la vista web con el fin de

administrar el servidor para dar de alta a los usuarios y al cliente del sistema.


95

● El módulo Account ha permitido dar de alta y definir la política de permisos de los

que iba a disponer cada uno de los usuarios del sistema. Importante hay que

destacar que, el sistema no permite el registro de usuarios como lo hace un sistema

público.

El sistema desarrollado exige que un administrador desde su vista administrativa

de Keycloak, registre y habilite a un usuario para que éste pueda acceder al

sistema. De hecho, el software API REST no incluye ninguna petición HTTPS

para dar de alta nuevos usuarios, por lo que, tan sólo un administrador de sistemas

con las credenciales válidas y desde un equipo habilitado para ello, puede acceder

al servidor de Keycloak para dar de alta a nuevos usuarios.

● El módulo de SSO Protocols se ha hecho uso al gestionar los procesos de

autenticación mediante el uso del protocolo OpenID Connect 2.0.

● El módulo User Storage permite almacenar de manera segura gracias a los

mecanismos de cifrado de la información, las credenciales de acceso de los

distintos usuarios del sistema.

● Por último, el módulo Events ha sido utilizado para dejar constancia mediante el

sistema de logs que incluye el servidor, de cualquier circunstancia que acontezca al

servidor. [31]


96

Proceso sistema con usuarios no autenticados

A lo largo del presente apartado se procederá a exponer de una manera mucho más visual y

fácil, cómo un sistema genérico que está utilizando un servidor Keycloak, gestiona una

petición no autenticada de un usuario. A modo de apoyo se incluye la imagen inferior que

proporciona un gráfico bastante ilustrativo extraído de la página oficial del servidor.

Imagen 37. Manejo de usuarios no autenticados

1. Llega una petición sin autenticar al sistema.

2. Cuando el sistema recibe la petición, redirige al usuario a la vista de “Login”, para

que éste se autentique antes de realizar cualquier tipo de petición.

3. Una vez el usuario ha introducido sus credenciales, el servidor procede a

validarlas.

a. Si el proceso de autenticación es correcto, el servidor emite un token de

sesión, cookie de sesión, JWT, etc. Dependiendo de la configuración

aplicada, el servidor emitirá un tipo de acceso u otro para ser utilizado por

el cliente del sistema.

b. Si el proceso finaliza de manera incorrecta, se informa al usuario del error

y no se emite ningún tipo de acceso al usuario.

4. A continuación, se redirige al usuario a la vista o página indicada. Cuando el

servicio API en este caso recibe la clave de acceso, procede a validarla contra

Keycloak.

5. Con el fin de validar la clave de acceso al sistema utilizada por un usuario, el

sistema contrasta utilizando un canal alternativo contra Keycloak la veracidad de

los datos recibidos.

6. Seguidamente, el Keycloak emitirá una respuesta en función del token recibido. Si

es correcto así se lo hará saber a la aplicación, de la misma manera que si el token

es inválido, manipulado o similar.


97

7. El usuario ya se encuentra totalmente autenticado en el sistema, y ya puede hacer

total uso del sistema dentro de sus permisos. [31]

Uso de tokens de acceso

Supongamos ahora que un usuario autenticado quiere realizar alguna acción contra el

servicio REST desarrollado. Cuando un usuario correctamente autenticado en el sistema

realiza una petición HTTPS, éste valida la veracidad del token utilizado. De la misma

manera que en el apartado anterior, con el fin de simplificar el proceso de comprensión del

procedimiento, se ha incluido una fotografía extraída del sitio web oficial del servidor

utilizado.

Imagen 38. Manejo de verficación de JWT


98

1. Un usuario autenticado realiza una petición API al sistema. Para ello, incluye en la

cabecera designada el token o clave de acceso al sistema.

2. El backend o proceso servidor procede a validar la veracidad de los datos. Como el

token, JWT o cualquier otro tipo de objeto emitido por Keycloak se manda firmado

por éste, se procede a validar dicha firma mediante la clave pública del reino

utilizado.

a. Para ello, el backend solicita a Keycloak la clave pública del reino o realm

del que está haciendo uso.

b. Keycloak le manda la clave pública solicitada, que como es pública no hay

problema en que sea conocida.

c. El servidor del servicio valida las credenciales. Si son correctas el proceso

continuo, en caso contrario se detiene.

3. Validando el token de acceso se comprueba posteriormente, que el usuario

disponga de los permisos necesarios para realizar la petición solicitada.

a. En caso afirmativo, se procesa la petición y se devuelven los datos

pertinentes.

b. En caso negativo, se deniega al usuario la realización de la petición. [31]


99

Adaptadores para Java

Como Keycloak es un servicio adicional del sistema, éste ofrece diversos adaptadores que

permiten a desarrollos realizados en cualquiera de los principales lenguajes de

programación, hacer uso de sus tecnologías. Por ello, Keycloak incluye diversos tipos de

adaptadores diferentes para aplicaciones Java, de hecho, incluye uno específico para ser

utilizado en aplicaciones basadas en Spring Boot. La selección del adaptador correcto

depende de la plataforma a utilizar. Cada adaptador de Java compatible con Keycloak se

puede configurar mediante un simple archivo JSON, como el que se muestra en la

siguiente imagen:

Imagen 39. Adaptadores para Java - Keycloak


100

A continuación, se muestra la utilidad de cada una de las directivas que el fichero

mencionado anteriormente admite.

● realm -> reino a utilizar

● resource -> identificador del cliente en ese reino

● realm-public-key -> clave pública (formato PEM) del reino que se va a utilizar

desde el cliente

● auth-server-url -> la URL base del servidor Keycloak

● ssl-required -> garantiza que toda la comunicación hacia y desde el servidor

Keycloak se realice a través de HTTPS.

● confidential-port -> el puerto que utiliza el servidor Keycloak para conexiones

seguras a través de SSL / TLS. Esto es OPCIONAL. El valor predeterminado es

8443.

● use-resource-role-mappings -> si se establece en verdadero, el adaptador buscará

dentro del token “role mappings” a nivel de aplicación para el usuario. Si es falso,

buscará en el nivel de dominio las asignaciones de roles de usuario. Esto es

OPCIONAL. El valor predeterminado es falso.

● public-client -> si se establece en verdadero, el adaptador no enviará las

credenciales del cliente a Keycloak. Esto es OPCIONAL. El valor predeterminado

es falso.

● enable-cors -> Esto habilita la compatibilidad con CORS. Manejará las solicitudes

de verificación previa de CORS. También examinará el token de acceso para

determinar los orígenes válidos. Esto es OPCIONAL. El valor predeterminado es

falso.

● cors-max-age -> si CORS está habilitado, esto establece el valor del encabezado

Access-Control-Max-Age. Esto es OPCIONAL. Si no se establece, este

encabezado no se devuelve en las respuestas CORS.

● cors-allowed-methods -> si CORS está habilitado, esto establece el valor del

encabezado Access-Control-Allow-Methods. Debe ser una cadena separada por

comas. Esto es OPCIONAL. Si no se establece, este encabezado no se devuelve en

las respuestas CORS.

● cors-allowed-headers -> si CORS está habilitado, esto establece el valor del

encabezado Access-Control-Allow-Headers. Debe ser una cadena separada por



● cors-exposed-headers -> si CORS está habilitado, esto establece el valor del

encabezado Access-Control-Expose-Headers. Debe ser una cadena separada por


101



● bearer-only -> esto debe establecerse como verdadero para los servicios. Si está

habilitado, el adaptador no intentará autenticar a los usuarios, solo verificará los

tokens de portador. Esto es OPCIONAL. El valor predeterminado es falso.

● autodetect-bearer-only -> esto debe establecerse en verdadero si su aplicación sirve

tanto para una aplicación web como para servicios web (por ejemplo, SOAP o

REST). Le permite redirigir a los usuarios no autenticados de la aplicación web a

la página de inicio de sesión de Keycloak, pero enviar un código de estado HTTP

401 a clientes SOAP o REST no autenticados, ya que no entenderían una

redirección a la página de inicio de sesión. Keycloak detecta automáticamente a los

clientes SOAP o REST basándose en encabezados típicos como X-Requested-

With, SOAPAction o Accept. El valor predeterminado es falso.

● enable-basic-auth -> esto le dice al adaptador que también admita la autenticación

básica. Si esta opción está habilitada, también se debe proporcionar el secreto. Esto

es OPCIONAL. El valor predeterminado es falso.

● expose-token -> si es verdadero, un cliente de navegador autenticado (a través de

una invocación HTTP de JavaScript) puede obtener el token de acceso firmado a

través de la URL root / k_query_bearer_token. Esto es OPCIONAL. El valor

predeterminado es falso.

● credentials -> especifica las credenciales de la aplicación. Esta es una notación de

objeto donde la clave es el tipo de credencial y el valor es el valor del tipo de

credencial. Actualmente se admite contraseña y jwt. Esto es REQUERIDO solo

para clientes con tipo de acceso 'Confidencial'.

● connection-pool-size -> esta opción de configuración define cuántas conexiones al

servidor Keycloak deben agruparse. Esto es OPCIONAL. El valor predeterminado

es 20.

● disable-trust-manager -> si el servidor Keycloak requiere HTTPS y esta opción de

configuración está establecida en true, no es necesario que especifique un almacén

de confianza. Esta configuración sólo debe usarse durante el desarrollo y nunca en

producción, ya que deshabilitará la verificación de certificados SSL. Esto es

OPCIONAL. El valor predeterminado es falso.

● allow-any-hostname -> si el servidor Keycloak requiere HTTPS y esta opción de

configuración se establece en verdadera, el certificado del servidor Keycloak se

valida a través del almacén de confianza, pero no se realiza la validación del

nombre de host. Esta configuración sólo debe usarse durante el desarrollo y nunca

en producción, ya que deshabilitará la verificación de certificados SSL. Esta


102

configuración puede ser útil en entornos de prueba. Esto es OPCIONAL. El valor

predeterminado es falso.

● proxy-url -> la URL del proxy HTTP, si se utiliza uno.

● truststore -> el valor es la ruta del archivo a un archivo de almacén de confianza. Si

antepone la ruta con classpath :, el almacén de confianza se obtendrá de la ruta de

clase de la implementación. Se utiliza para las comunicaciones HTTPS salientes al

servidor Keycloak. Los clientes que realizan solicitudes HTTPS necesitan una

forma de verificar el host del servidor con el que están hablando. Esto es lo que

hace el fideicomisario. El almacén de claves contiene uno o más certificados de

host de confianza o autoridades de certificación. Puede crear este almacén de

confianza extrayendo el certificado público del almacén de claves SSL del servidor

Keycloak. Esto es OBLIGATORIO a menos que ssl-required sea none o disable-

trust-manager sea verdadero.

● truststore-password -> contraseña del almacén de confianza. Esto es obligatorio si

el almacén de confianza está configurado y el almacén de confianza requiere una

contraseña.

● client-keystore -> esta es la ruta del archivo a un archivo de almacén de claves.

Este almacén de claves contiene un certificado de cliente para SSL bidireccional

cuando el adaptador realiza solicitudes HTTPS al servidor Keycloak. Esto es

OPCIONAL.

● client-keystore-password -> contraseña para el almacén de claves del cliente. Esto

es OBLIGATORIO si se establece el almacén de claves del cliente.

● client-key-password -> contraseña de la clave del cliente. Esto es OBLIGATORIO

si se establece el almacén de claves del cliente.

● always-refresh-token -> si es verdadero, el adaptador actualizará el token en cada

solicitud. Advertencia: cuando está habilitado, esto dará como resultado una

solicitud a Keycloak para cada solicitud a su aplicación.

● register-node-at-startup -> si es verdadero, el adaptador enviará la solicitud de

registro a Keycloak. Es falso de forma predeterminada y útil solo cuando la

aplicación está agrupada. Consulte Agrupación en clústeres de aplicaciones para

obtener más detalles.

● register-node-period -> período para volver a registrar el adaptador a Keycloak.

Útil cuando la aplicación está agrupada. Consulte Agrupación en clústeres de

aplicaciones para obtener más detalles.

● token-store -> los valores posibles son sesión y cookie. El valor predeterminado es

sesión, lo que significa que el adaptador almacena la información de la cuenta en la

sesión HTTP. Una cookie alternativa significa el almacenamiento de información


103

en una cookie. Consulte Agrupación en clústeres de aplicaciones para obtener más

detalles

● token-cookie-path -> cuando se utiliza una tienda de cookies, esta opción establece

la ruta de la cookie utilizada para almacenar la información de la cuenta. Si es una

ruta relativa, se supone que la aplicación se ejecuta en una raíz de contexto y se

interpreta en relación con esa raíz de contexto. Si es una ruta absoluta, entonces la

ruta absoluta se usa para establecer la ruta de la cookie. Predeterminado para usar

rutas relativas a la raíz de contexto.

● principal-attribute -> atributo OpenID Connect ID Token con el que completar el

nombre de UserPrincipal. Si el atributo de token es nulo, el valor predeterminado

es sub. Los valores posibles son sub, nombre_usuario_preferido, correo

electrónico, nombre, apodo, nombre_proporcionado, nombre_familia.

● turn-off-change-session-id-on-login -> la identificación de la sesión se cambia de

forma predeterminada en un inicio de sesión exitoso en algunas plataformas para

conectar un vector de ataque de seguridad. Cámbielo a verdadero si desea

desactivarlo. Esto es OPCIONAL. El valor predeterminado es falso.

● token-minimum-time-to-live -> cantidad de tiempo, en segundos, para actualizar

de forma preventiva un token de acceso activo con el servidor Keycloak antes de

que expire. Esto es especialmente útil cuando el token de acceso se envía a otro

cliente REST donde podría caducar antes de ser evaluado. Este valor nunca debe

exceder la vida útil del token de acceso del reino. Esto es OPCIONAL. El valor

predeterminado es 0 segundos, por lo que el adaptador actualizará el token de

acceso solo si está vencido.

● min-time-between-jwks-requests -> cantidad de tiempo, en segundos, que

especifica el intervalo mínimo entre dos solicitudes a Keycloak para recuperar

nuevas claves públicas. Son 10 segundos por defecto. El adaptador siempre

intentará descargar una nueva clave pública cuando reconozca el token con un niño

desconocido. Sin embargo, no lo intentará más de una vez cada 10 segundos (de

forma predeterminada). Esto es para evitar DoS cuando el atacante envía muchos

tokens con bad kid obligando al adaptador a enviar muchas solicitudes a Keycloak.

● public-key-cache-ttl -> cantidad de tiempo, en segundos, que especifica el

intervalo máximo entre dos solicitudes a Keycloak para recuperar nuevas claves

públicas. Es 86400 segundos (1 día) por defecto. El adaptador siempre intentará

descargar una nueva clave pública cuando reconozca el token con un niño

desconocido. Si reconoce el token con un niño conocido, sólo usará la clave

pública descargada anteriormente. Sin embargo, al menos una vez por este


104

intervalo configurado (1 día por defecto) se descargará siempre una nueva clave

pública, incluso si el niño del token ya es conocido.

● ignore-oauth-query-parameter -> el valor predeterminado es falso; si se establece

en verdadero, se desactivará el procesamiento del parámetro de consulta

access_token para el procesamiento del token de portador. Los usuarios no podrán

autenticarse si solo pasan un access_token

● redirect-rewrite-rules -> si es necesario, especifique la regla de reescritura de URI

de redireccionamiento. Esta es una notación de objeto donde la clave es la

expresión regular con la que se debe hacer coincidir el URI de redireccionamiento

y el valor es la Cadena de reemplazo. El carácter $ se puede usar para referencias

inversas en la cadena de reemplazo.

● verify-token-audience -> si se establece en verdadero, durante la autenticación con

el token de portador, el adaptador verificará si el token contiene este nombre de

cliente (recurso) como audiencia. La opción es especialmente útil para los

servicios, que principalmente atienden solicitudes autenticadas por el token de

portador. Está configurado como falso de forma predeterminada; sin embargo, para

mejorar la seguridad, se recomienda habilitarlo. [31]


105

2.4.11.3. MariaDB

Como gestor de bases de datos, se ha hecho uso de MariaDB

que es un motor derivado del más que conocido MySQL. El

gestor utilizado cuenta con licencia de uso GPL, lo que viene a

significar que se trata de un software abierto y gratuito para ser

utilizado por cualquier persona interesada.

Se trata de un software desarrollado por el propio fundador de MySQL, la fundación

MariaDB y la comunidad de desarrolladores de código libre. Una de las principales

ventajas de MariaDB es su fácil utilización, ya que, si se ha trabajado anteriormente con

bases de datos MySQL, cualquier persona puede hacer uso de MariaDB de la misma

manera, debido a que los comandos internos, interfaces, APIs y bibliotecas del sistema son

los mismos o prácticamente iguales, facilitando a nuevos usuarios su utilización

enormemente.

Esto ha sido uno de los grandes atractivos de MariaDB a la hora de captar nuevos usuarios,

porque permite a usuarios de MySQL utilizar código libre, con todas las ventajas que ello

incluye y abandonar el software privativo. Todo ello, sin tener que pasar por una curva de

aprendizaje prolongada, ya que, en un periodo muy reducido se pueden aprender las pocas

diferencias entre ambos sistemas.

Actualmente, MariaDB dispone de 5 versiones distintas del motor que cuentan con soporte:

● 10.6

● 10.5

● 10.4

● 10.3

● 10.2

En el sistema desarrollado en colaboración con la empresa Altia, se ha hecho uso de la

versión 10.5, en el momento en el que se inició el proyecto era la más reciente.

Posteriormente, se ha publicado la versión 10.6 que incluye algunas mejoras y solución a

ciertas vulnerabilidades detectadas. En concreto, para la versión utilizada que ha sido la

10.5.9, se conoce a fecha de redacción del presente documento una vulnerabilidad crítica

con código CVE-2021-27928, por lo que, en caso de trasladar el sistema a un entorno de

https://www.cvedetails.com/cve/CVE-2021-27928/


106

producción, se recomienda encarecidamente actualizar el motor de bases de datos a la

última versión disponible para solucionar este problema.

Mejoras con respecto a MySQL

Es cierto que MariaDB utiliza mecanismos para simplificar el proceso de aprendizaje a los

recién llegados desde motores MySQL, pero también incluye una serie de técnicas que

mejoran al SGBD MySQL en diversos apartados, y a continuación se detallan algunos de

ellos.

● Mecanismos de almacenamiento

○ Como alternativa a MyISAM en MariaDB se proporciona Aria que tiene

como principal ventaja su mayor fortaleza y estabilidad, lo que reduce de

manera significativa el número de caídas.

○ A partir de la versión 10.0 se incluyen mecanismos basados en el motor de

base de datos Cassandra, para gestionar datos NoSQL. Su funcionamiento

es limitado por el momento, pero ya sienta las bases para poder utilizar

MariaDB como una base de datos NoSQL.

○ Se ha reemplazado el motor de gestión de almacenamiento InnoDB por

XtraDB. Este nuevo motor incorpora el diseño compatible con ACID de

InnoDB y la arquitectura MVCC, lo que permite un mayor grado de ajuste

y escalabilidad. Asimismo, el motor también se adapta mejor al

procesamiento de procesadores con muchos núcleos, lo que soluciona

algunos de los problemas conocidos por InnoDB.

● Facilidad de uso

○ Permite definir columnas virtuales a las tablas deseadas por el usuario.

○ Se proporcionan estadísticas de índices y tablas a través de nuevas tablas

de la base de datos INFORMATION_SCHEMA, así como se ofrecen

nuevas utilidades mediante los comandos FLUSH y SHOW.

○ Se han introducido características similares a los gestores de bases de

datos NoSQL, como HandlerSocket. Esto proporciona acceso directo a

tablas del gestor InnoDB saltando la capa SQL, que en ocasiones puede

resultar problemática.

https://dev.mysql.com/doc/refman/8.0/en/myisam-storage-engine.html


107

● Prestaciones

○ El optimizador de MariaDB hace que el núcleo del SGBD ofrezca un

rendimiento más elevado que el de alternativas como MySQL.

○ Durante tareas de replicación se han introducido significativas mejoras de

rendimiento en las últimas versiones. En concreto, para algunas

ejecuciones el rendimiento es prácticamente el doble. [32]


108

2.4.11.4. Alpine + JDK8 + Maven

Para servir el desarrollo realizado bajo Spring Boot se

ha hecho uso de un contenedor basado en la distribución

de Linux llamada Alpine.

Alpine Linux es una distribución del sistema operativo de código libre basada en musl y

Busybox, teniendo como principal objetivo el proporcionar a sus usuarios un sistema

operativo lo más ligero posible, pero siempre teniendo en cuenta la seguridad como un

aspecto fundamental a tener siempre en cuenta. Asimismo, el sistema operativo pretende

que pueda ser útil para tareas de propósito general, pero sus aplicaciones se encuentran

principalmente en routers profesionales, cortafuegos, VPNs y servidores. [33]

Se trata de una distribución con tanta optimización que la imagen oficial de Alpine para

Docker tiene un tamaño inferior a los 5MB, de ahí que, esta distribución sea especialmente

conocida por poder ejecutarse directamente en la memoria RAM de prácticamente

cualquier dispositivo moderno.

Dadas las limitaciones del servidor utilizado y que las aplicaciones desarrolladas en Java

no son las más eficientes a nivel de recursos requeridos, se ha visto en la necesidad de

buscar una imagen que fuera lo más eficiente posible, al mismo tiempo que, las

características de seguridad requeridas para el sistema se cumplieran, con el fin de reducir

los recursos empleados por el contenedor.

Dado el tamaño de la imagen de Alpine (inferior a 5 MB) la lista de paquetes de Linux

instalados por defecto es muy reducida, por lo que, se ha visto en la necesidad de

personalizar la imagen de oficial para añadirle los paquetes de Maven y del JDK 8, con el

fin de poder compilar y ejecutar normalmente la aplicación desarrollada.

Por lo tanto, se dispone de una imagen con los mínimos paquetes necesarios para que ésta

funcione correctamente, y con la finalidad de poder ejecutar y servir el desarrollo

realizado, se han instalado los paquetes de Maven y JDK 8.

https://www.musl-libc.org/

https://busybox.net/


109

2.4.11.5. NetData

Por último, y para concluir con el presente apartado de la

memoria dedicado a los contenedores Docker, destacar que, se

ha hecho uso del contenedor oficial de NetData con el que se

ha monitorizado el uso de los distintos componentes tanto del

sistema como físicos del servidor.

NetData es una herramienta que permite visualizar desde cualquier navegador web una

enorme cantidad de datos de monitorización recopilados en tiempo real sobre un equipo

con sistema operativo Linux. A parte de ofrecer los datos tradicionales como uso de CPU,

uso de memoria RAM, velocidad de disco, etc, también ofrece otros menos convencionales

y muy útiles para la correcta monitorización del sistema como pueden ser consultas SQL,

conexiones VPN y peticiones API realizadas.

Como se trata de una herramienta de monitorización, es fundamental que la cantidad de

recursos consumidos por la misma sean los menores posibles, con el objetivo de ofrecer

unas métricas lo más fidedignas posibles. Tanto es así que, para una mayor optimización,

es una herramienta desarrollada en su mayoría en C.

Su eficiencia llega a un nivel tan elevado que en un equipo como una Raspberry, que tiene

un núcleo muy poco potente en comparación a un servidor o equipo de sobremesa

moderno, no se llega a consumir ni un 5% de la CPU con todos los contenedores en

ejecución, pero sin tráfico de usuarios.

También destacar que, el sistema también incluye un entorno de alertas personalizables por

las que, si el sistema se encuentra bajo ciertas condiciones, se puede configurar para que

por ejemplo envíe un correo electrónico o SMS alertando al administrador de la

circunstancia. También se incluye una sección específica en lo referente a alertas, en la que

se pueden visualizar las actuales y un historial para ver las ocurridas en el pasado.

Por último, se muestran algunas fotografías ilustrativas de secciones de la página web que

genera NetData con toda la información. [34]

https://hub.docker.com/r/netdata/netdata

https://informatica.uv.es/estguia/ATD/apuntes/laboratorio/Lenguaje-C.pdf


110

Imagen 40. Funcionamiento NetData


111

2.4.12. SSH

El protocolo Secure SHell o también conocido como SSH es una

aplicación que funciona bajo el protocolo TCP en el puerto 22 por

defecto.

Mediante este protocolo se puede obtener acceso remoto bajo línea de comandos a un

servidor de manera segura (se debe utilizar la versión 2), tal y como su propio nombre

indica, toda la comunicación entre un cliente SSH y el proceso servidor va totalmente

cifrada.

Toda esta comunicación se realiza de manera segura, debido a que, se realiza a través de un

túnel SSH, que se genera entre ambos extremos de la comunicación cuando una nueva

sesión se produce. Además, gracias a diversas técnicas de cifrado aplicadas sobre la

comunicación que viaja dentro del túnel, cualquier información va de manera ilegible,

incluido el usuario y su correspondiente contraseña, siendo esto último una clara diferencia

con respecto a otros protocolos como Telnet. [35]

El acceso al servidor se realiza mediante este protocolo, como modo de protección, algo

fundamental teniendo en cuenta que, se trata de un servidor sin interfaz gráfica y sin una

conexión física a un monitor, ha sido mediante SSH mediante el que se ha establecido una

conexión remota para gestionar y administrar todo lo necesario para configurar y securizar

el equipo.

Con el fin de securizar dicho acceso se han aplicado una serie de medidas, quedando la

mayoría de ellas resumidas en el siguiente listado:

● El servicio tan sólo es accesible desde la red local o en su defecto desde una

conexión VPN, es decir, no es un servicio expuesto a internet de manera directa.

● El puerto empleado no ha sido el de por defecto.

● Se encuentra oculto gracias a la técnica del Port Knocking.

● El acceso al servidor requiere de una clave RSA privada de 4096 bits.

● Si el acceso se realiza fuera del horario definido (8:30-19:30), se solicita también

un código para ejecutar un doble factor de autenticación. El código se puede

obtener mediante la aplicación de Google Authenticator.

https://www.welivesecurity.com/la-es/2013/03/08/port-knocking-para-reforzar-la-seguridad-de-un-servidor/

https://www.google.com/landing/2step/?hl=es_419


112

● Además, si el acceso se realiza entre medianoche y las 6 de la madrugada, el

servicio envía un correo electrónico.

Por último, si se producen 3 intentos seguidos fallidos de autenticación, otro correo

electrónico es enviado de manera automática, bloqueando también la dirección IP desde la

que se realizaron los intentos.


113

2.5. Diseño de la aplicación


114

El sistema API REST desarrollado utilizando el framework Spring, presenta un diseño con

diversas clases Java así como entidades de base de datos, todo ello con el objetivo de poder

ofrecer un sistema lo más desacoplado, organizado y eficiente posible.

Al disponer de un sistema con un grado tan alto de desacoplamiento, cada clase del sistema

tiene sus responsabilidades correctamente delimitadas, lo que repercute de manera directa

en una mayor facilidad y fiabilidad a la hora de añadir mejoras y/o corregir errores.

Además, un gran desacoplamiento favorece tanto la reusabilidad como la mantenibilidad

del código fuente generado para proporcionar una buena experiencia al usuario, al mismo

tiempo que, no se pierde de vista la seguridad, siendo esto último un aspecto crítico en

sistemas que manejan información sensible como el desarrollado. Se debe tener en cuenta

que cuanto más claro, sencillo y estructurado se redacte el código fuente de una

herramienta más fácil será de entender y analizar por todo el mundo, lo que repercute de

manera directa en algunos aspectos como:

● La detección de errores podría ser posible simplemente leyendo el código.

● La realización de pruebas será más rápida y eficaz.

● Los procesos de auditoría serán mucho menos complejos.

Esto unido al modelo “vista controlador” correctamente aplicado, proporciona un sistema

con una gran cantidad de archivos, pero delegando en cada uno de ellos ciertos aspectos

muy concretos. Así, añadir elementos al sistema o modificar ciertos comportamientos del

mismo, debería ser un proceso totalmente transparente para el resto de los elementos no

involucrados.

En cuanto al sistema como se puede ver en 16 clases principales distintas que son:

● Address -> Representa la dirección asociada a un ciudadano.

● Citizen -> Se trata de la clase padre con la que se quiere generalizar la idea de

Paciente, Personal Sanitario y de un Administrador de Sistemas. Por ello, se

incluyen en ella datos genéricos que cualquier persona posee.

● Patient -> Representa los datos de un paciente y tiene relación con las siguientes

clases:

○ History -> Representa un registro del historial médico de un paciente. Por

ello, el historial médico total de un paciente se compone de diversos

registros de la clase History.


115

○ Access Register -> Permite registrar cualquier tipo de acción (Lectura o

Escritura) sobre el historial de un paciente, así como de cualquiera de sus

datos.

● Health Personnel -> Se trata de una nueva generalización, que en este caso sirve

para representar la idea de un Médico, Enfermero o de un Trabajador Social.

○ Doctor -> Permite definir y gestionar de una manera mucho más particular

y específica a los médicos con acceso al sistema.

○ Nurse -> Permite definir y gestionar de una manera mucho más particular

y específica a los enfermeros y enfermeras con acceso al sistema.

○ Social Worker -> Igual que con los dos casos anteriores, permite definir y

gestionar de una manera mucho más particular y específica a los

enfermeros y enfermeras con acceso al sistema.

Al haberse hecho una especificación más concreta de los tipos de personal

sanitario con acceso al sistema, se puede

Además, esta clase además tiene relación con otras que son:

○ Device -> Permite definir y gestionar los diversos dispositivos a un

sanitario. Esto permite proporcionar una capa de seguridad adicional, tan

sólo permitiendo que un sanitario pueda acceder al sistema si está

utilizando un dispositivo habilitado para ello, y que además, está asociado

a su usuario. En caso contrario se deniega cualquier tipo de intento de

conexión contra el servidor.

○ Digital Certificate -> Permite definir y gestionar de manera fiable los

distintos certificados emitidos por la aplicación. Mediante dichos

certificados se puede validar y autenticar de manera inequívoca las

acciones realizadas por un sanitario o administrador de sistemas, ya que,

cualquier petición necesita de una firma digital.

● System Administrator -> Se trata de una especificación de la clase Citizen, con la

que se quiere definir y gestionar de la manera más apropiada y fiable las acciones a

las que los administradores de sistemas tienen acceso. Al igual que otras clases

anteriores, la referente a los administradores de sistemas también tiene relaciones

con otras clases:


116

○ Digital Certificate -> Tal y como se ha indicado anteriormente, permite

definir y gestionar los certificados que en este caso los administradores

utilizan para realizar las distintas gestiones. Así mismo, dado su posición

en el sistema, también son los encargados de generar, renovar y revocar

certificados digitales al resto de los usuarios del sistema.

○ Device -> En este caso el sistema está sólo pensado por motivos de

seguridad para que, un administrador tan sólo pueda acceder al sistema,

sólo si este se encuentra físicamente frente a su equipo de trabajo

destinado. Por lo tanto, el acceso remoto al sistema para los

administradores se encuentra bloqueado, reduciendo el rango de ataque de

un atacante y mejorando la seguridad del sistema.

○ Audit -> Se trata de una clase similar a Access Register pero destinada a

registrar de manera explícita las acciones (Lectura o Escritura,

Modificación o Borrado) realizadas por estos usuarios en particular.

● Audit Action -> Se trata de una enumeración para gestionar las acciones permitidas

por los usuarios. Contiene 4 valores: “READ”, “WRITE”, “UPDATE” y

“DELETE”.

● Active-> Se trata de una enumeración para controlar si un usuario está activo y

puede acceder al sistema. Contiene 2 valores: “YES”, “NO”.

● Document Type -> Se trata de una enumeración para definir los tipos posibles de

documentos de identidad que el sistema admite. Contiene 3 valores: “DNI”, “NIE”,

“PASSPORT”.

Tras aplicar el modelo MVC descrito anteriormente en el presente documento, así como

tras la generación de los distintos adicionales requeridos por el sistema (controladores,

excepciones, archivos de configuración, etc), el desarrollo total incluye 178 archivos de

código fuente, por lo que, como se puede intuir no se trata de un desarrollo pequeño y que

éste se encuentra altamente desacoplado tal y como se ha indicado.


117

2.6. Arquitectura de la aplicación

A continuación, se muestra un diagrama con el que se pretende ilustrar el diseño de la

arquitectura global utilizada en el sistema desarrollado para el presente trabajo final de máster.

Como se puede ver en la imagen inferior, para poder acceder al sistema, los dispositivos

móviles asociados a los sanitarios deben establecer un túnel VPN entre ellos y el servidor del

sistema, ya que, aparte de que se quiere establecer un túnel seguro por el que viaje toda la

comunicación, el servicio REST tal y como se ha venido comentando hasta el momento, no es

un servicio accesible de manera directa desde internet, ya que, tan sólo es accesible y atiende

peticiones que provengan desde equipos de la red física local de la instalación y de dispositivos

conectados a la VPN.

Imagen 41. Arquitectura del sistema


118

Una vez el equipo tiene un túnel VPN generado, ya puede acceder al servicio REST para lo que en

primer lugar tendrá que autenticarse contra el servidor Keycloak para obtener el JWT, que como se

ha expuesto, anteriormente, es un requisito indispensable para poder hacer uso del servicio REST

diseñado, ya que, cualquier petición realizada en el sistema va debidamente autenticada.

Destacar que, pese a que el sistema se haya establecido en un único servidor está perfectamente

planteado para poder distribuirse en diversos servidores si así se desea, así cada uno de los

servicios hace uso de certificados SSL con los que se cifra cualquier tipo de comunicación,

estableciendo un grado más de seguridad que prevenga de cualquier tipo de fuga de información.


119

3. Funcionalidades del sistema

A lo largo de este tercer apartado de la memoria, se van a mostrar las funcionalidades que el

sistema ofrece, una vez el usuario ha accedido a este. Por lo tanto, se van a mostrar las distintas

peticiones API que el sistema ofrece, pero sin profundizar en ellas, y será en el apartado de

resultados donde se profundizará un poco más en este aspecto.

Además, destacar que debido a un acuerdo de confidencialidad no se podrá exponer con un alto

grado de detalle el funcionamiento interno del sistema, pero aún así, se expondrá de forma

comprensible.

Con el objetivo de documentar y facilitar tanto el proceso de análisis del funcionamiento de cada

llamada API en profundidad, así como de los métodos utilizados por el servicio desarrollado bajo el

framework Spring, se ha documentado todo mediante dos métodos que son: Swagger y JavaDoc.

3.1. Swagger

Se trata de un conjunto de herramientas de código libre desarrolladas

originalmente por la organización SmartBear Software, que se

encuentran integradas dentro de un mismo ecosistema con el objetivo

de facilitar las tareas de diseño, construcción, utilización y

documentación de servicios web basados en el principio RESTful.

Una de las herramientas más utilizadas, es Swagger UI Tool, que como veremos más adelante

permite utilizar Swagger de manera totalmente gráfica a través de un navegador web.

Para generar toda la documentación necesaria, Swagger se basa en SpringFox, que es un

conjunto de librerías de Java que tienen como objetivo, permitir la automatización de

especificaciones de sistemas desarrollados bajo Spring, tanto por equipos informáticos como

por humanos. Todo ello se puede realizar mediante el uso de etiquetas o anotaciones Java

propias de Swagger.

Destacar que, no es la única opción a la hora de documentar servicios REST en Spring Boot, ya

que, existen otras alternativas como Spring REST Docs, que ofrece características similares a

Swagger y que también es muy fácil de utilizar e integrar en un proyecto, debido a que se trata

de un subproyecto oficial dentro del framework Spring.

https://springfox.github.io/springfox/docs/current/

https://spring.io/projects/spring-restdocs


120

3.1.1. Swagger integrado en Spring Boot

Ahora, procederemos a exponer el procedimiento necesario con el que se podrá integrar

Swagger dentro de una aplicación basada en Spring Boot. En concreto, esta integración se

ha realizado de manera satisfactoria utilizando la versión 2.4.4 de Spring Boot.

El primer paso para incluir Swagger dentro del proyecto, es el de añadir las siguientes

dependencias al fichero “pom.xml”:

Imagen 42. pom.xml

Al añadir y descargar las dependencias anteriores, ya podremos desde nuestro proyecto de

Spring Boot acceder a las librerías necesarias para integrar Swagger.

El siguiente paso consistirá en generar una clase Java para configurar el funcionamiento de

Swagger, como se muestra a continuación:


121

Imagen 43. Configuración Swagger en Spring Boot

Mediante el método que se muestra en la imagen superior estaremos indicando entre otros

elementos, el tipo de documentación que debe generar (documentación del tipo Swagger),

el contexto de seguridad a aplicar, así como las rutas de los archivos que se deben incluir

durante el proceso de documentación, que en este caso han sido todos los controladores

que atienden las peticiones API REST de los clientes.

Tras ello, tan sólo nos restará por iniciar nuestro servidor de Spring Boot y acceder al

recurso “/swagger-ui.html”, que si se ha seguido el procedimiento correctamente debería

ofrecer un resultado como el siguiente:


122

Imagen 44. Interfaz Web Swagger


123

3.1.2. Swagger UI

Tal y como se ha podido comprobar en la última imagen del apartado anterior, se han

detectado de manera totalmente automática los controladores utilizados en el servicio

REST, para los que, si hacemos ‘click’ sobre cualquiera de ellos podremos ver cada uno de

los métodos Java encargados de procesar cada petición HTTPS en particular, como es el

caso del controlador “Access Register” de la imagen inferior:

Imagen 45. Access Register - Swagger UI

Para que la información de la imagen anterior pueda aparecer de esa manera en la vista de

usuario de Swagger, es necesario proporcionar a Swagger la información que desea que

éste utilice para generar informes.

Por ejemplo, para el caso particular del controlador “Access Register” se han utilizado

principalmente 3 etiquetas Java propias de Swagger que son: “@Api”, “@ApiOperation”

y “@GetMapping”. Es cierto que existen más etiquetas que podrían permitir documentar

de una manera más intensa el sistema, pero es algo que no se ha considerado necesario, ya

que, junto con la documentación generada utilizando JavaDoc, ya se puede disponer de una

imagen lo suficientemente clara como para poder utilizar la API desarrollada sin

problemas.

Mediante la etiqueta “@Api” indicamos el nombre identificador de la clase que queremos

que aparezca en la vista de usuario de Swagger. En este caso el nombre utilizado ha sido

“Access Register”, que como se puede ver en la imagen inferior, se ha indicado de la

siguiente manera.

Imagen 46. Etiqueta Java para Swagger


124

A continuación, si se quiere proporcionar información detallada sobre el uso de una

petición HTTPS como puede ser la mostrada en la imagen inferior

(“/accessRegister/byHealthPersonnel”), todo ello se puede hacer utilizando las etiquetas

“@ApiOperation” y “@GetMapping”.

Imagen 47. Documentación petición REST utilizando Swagger

Mediante la primera de ellas, podemos hacer una pequeña explicación de la utilidad de

dicha petición HTTPS. Asimismo, también podemos explicar los parámetros requeridos

que se deben proporcionar junto con la petición. En este caso, como se puede ver tanto en

la imagen inferior como superior, la petición requiere de un objeto JSON que incluya dos

atributos: “idCitizen” y “idSocialSecurity”.


125

Imagen 48. Documentación para Swaggeer en código fuente

Por último, mediante la etiqueta “@GetMapping” se indica que la petición es de tipo GET

y que su resultado será un objeto JSON.

En cuanto a los posibles códigos HTTP que la petición puede generar, son

automáticamente detectados por el software Swagger y se incluyen automáticamente. Se

podría proporcionar más detalle sobre los mismos utilizando la etiqueta

“@ApiResponse()”.

En caso de requerir otro tipo de dato más común como puede ser un ‘String’, Swagger

permitirá introducir el valor de dicho dato mediante un campo de texto, añadiendo a la

petición HTTPS que realizará al servidor el valor incluido por el usuario.

Imagen 49. Uso del servicio a través de Swagger


126

3.1.3. Swagger junto con el servicio desarrollado

Como se ha comentado anteriormente, una de las funcionalidades que ofrece Swagger

además de documentar un servicio RESTful, es poder interactuar con el sistema sin la

necesidad de tener que desarrollar ningún cliente o sistema similar.

Para ello, dado que todas las peticiones API requieren de un proceso de autenticación y

autorización realizado a partir de un token JWT, emitido por el servidor del sistema

encargado de dichas tareas, para poder hacer uso del servicio a través de Swagger, será

necesario proporcionar dicho token, en caso contrario, cualquier petición será denegada.

Para solucionar este problema, Swagger incluye una opción llamada “Authorize” donde

podemos incluir el JWT que se debe enviar al servicio REST, tal y como se puede ver en la

imagen inferior.

Imagen 50. JWT en Swagger UI

Finalmente, si procedemos a realizar una petición al servicio REST desarrollado, podremos

comprobar como efectivamente se puede utilizar también el conjunto de herramientas

Swagger para validar y monitorear el correcto funcionamiento del servicio desarrollado.

Para el caso del presente ejemplo, se ha hecho uso de una petición que devuelve los datos

de un ciudadano registrado en el sistema a partir de su DNI.


127

Imagen 51. Petición REST utilizando Swagger

Tal y como se puede comprobar en la imagen superior, se introduce en el campo

designado, el ID del usuario que como se ha dicho anteriormente es su DNI. Por último,

para obtener el resultado se debe presionar el botón que pone “Execute”, que nos realizará

la petición HTTPS correspondiente, ofreciendo el siguiente resultado:

Imagen 52. Resultado petición REST en Swagger


128

3.2. JavaDoc

JavaDoc es una manera propuesta por la empresa Oracle con la

que generar documentación de una manera sencilla e intuitiva,

de cualquier tipo de desarrollo software basado en el lenguaje de

programación Java. Por lo tanto, JavaDoc es una alternativa más

que puede ser utilizada en desarrollos basados en Spring Boot,

así como para documentar desarrollos de sistemas REST.

Dada su facilidad de uso junto con el gran abanico de opciones que ofrece el estándar, ha

hecho que JavaDoc sea hoy en día el referente en temas de documentación de sistemas que

hacen uso de Java.

Es por ello, que la mayoría de IDEs como Visual Studio Code o IntelliJ incluyen soporte

de manera oficial y mediante extensiones de terceros, que facilitan el proceso de

construcción tanto de la documentación como de la generación de esta.

Su uso es muy sencillo y se reduce a conocer ciertas etiquetas reservadas para su uso

exclusivo en JavaDoc, siendo algunas de ellas las siguientes:

● “@author” -> Permite indicar el nombre del desarrollador.

● “@version” -> Permite indicar la versión de por ejemplo un método.

● “@param” -> Permite explicar un parámetro requerido por un método y su

utilidad.

● “@return” -> Permite informar sobre el tipo de objeto y/o contenido que devuelve

un método, a excepción de los métodos ‘void’.

● “@throws” -> Permite definir y explicar las excepciones que se lanzan en un

método, así como el motivo o los motivos por los que estas pueden ser generadas.

● “@see” -> Permite asociar a un método con otro o con otra clase.

● “@deprecated” -> Permite indicar si un método ha quedado obsoleto.

Expuesto brevemente el funcionamiento de JavaDoc, se va a mostrar un ejemplo real

llevado a cabo en el sistema, en el que se ha documentado tanto con Swagger como con

JavaDoc, la llamada HTTPS que atiende cuando se quiere visualizar el historial médico de

un paciente determinado. Como se puede ver en la imagen inferior, se ha proporcionado

una pequeña descripción del objetivo del método Java, así como se ha indicado el tipo de

dato necesario que en este caso es un objeto JSON. Por último, también se indica el tipo de

dato devuelto, que en este caso es una instancia de “ResponseEntity”.


129

Imagen 53. Documentación JavaDoc en el código fuente

Una vez documentado todo el sistema y utilizando la utilidad proporcionada por IntelliJ

Ultimate, se ha procedido a generar toda la documentación con JavaDoc, que se ofrece a

través de ficheros HTML, por lo que, para su visualización será necesario disponer de un

navegador web con el que visualizar su contenido adecuadamente. Una vez se ha accedido

al fichero “index.html”, para el caso del sistema desarrollado se obtiene el siguiente

resultado:


130

Imagen 54. Documentación JavaDoc - 1

Si buscamos la clase “HistoryController” que es donde se encuentra el método indicado

anteriormente, se obtiene el siguiente resultado:


131


Finalmente, accediendo al método llamado “one” se puede ya visualizar, de una manera

clara, toda la información que se ha incluido en el fichero de código fuente de Java.


Por lo tanto, la documentación de cualquier sistema es crucial, ya que, permite a otros

desarrolladores entender de una manera mucho más clara el funcionamiento del sistema.

Así se facilitan las tareas de mantenimiento, actualizaciones y soluciones de errores y

vulnerabilidades encontradas.


132

4. Resultados

Durante el presente apartado de la memoria, se procederán a exponer las distintas peticiones API

desarrolladas para el presente proyecto, así como se demostrará el correcto funcionamiento de

algunas de ellas. No se procederá a mostrar en detalle la totalidad de las peticiones que admite el

sistema por motivos contractuales.

Para llevar a cabo la presente demostración, se hará uso de la herramienta Postman, ya que,

después de utilizar diversas herramientas como Swagger o CURL, se ha llegado a la conclusión de

que al menos para el presente proyecto, Postman incluye todas las características necesarias para

hacer uso del servicio REST en una misma herramienta o entorno.

También resaltar que, a modo de verificación global del sistema, las siguientes pruebas se van a

realizar mediante un equipo portátil tanto a través de una conexión WiFi en la misma red en la que

se encuentra el servidor, como a través de una conexión VPN utilizando el cliente de WireGuard y

una conexión de datos móviles.

Con el objetivo de que este proceso resulte claro y sencillo de entender, he añadido 9 subapartados,

a través de los cuales se expondrán de manera detallada las distintas características que cada uno de

los controladores12 o controllers que el sistema incluye.

12 Ver en el glosario


133

4.1. Ciudadano (Citizen)

Como se puede apreciar en la imagen inferior, en cuanto al manejo de la información

referente a los ciudadanos registrados en el sistema, se disponen de 5 peticiones REST,

siendo dos de ellas del tipo GET y el resto del tipo DELETE, POST y PUT.

Imagen 57. CitizenController

Además, gracias al uso de Swagger UI podemos ver que para cada una de las peticiones

que el controlador para ciudadanos admite, se incluye una pequeña descripción indicando

la utilidad de cada una de ellas.

Aclarado lo anterior, a continuación, se va a proceder a mostrar el correcto funcionamiento

del método POST, que como se indica en la imagen superior, permite dar de alta o registrar

a un nuevo ciudadano en el sistema. Por ello, utilizando el software Postman, se ha

configurado el entorno de la siguiente manera para realizar correctamente la petición:

1. Se ha seleccionado que el método HTTP a utilizar sea del tipo POST.

2. Se ha indicado la URL a utilizar, siendo en este caso

“https://192.168.100.51:8443/citizen/newCitizen”, ya que, tal y como se muestra

en la imagen inferior, se ha hecho uso de una variable llamada “HTTPS raspberry”

que hace referencia a la parte común que cualquier petición tiene.

3. Además de la cabecera “Authorization” donde se ha incluído el JWT precedido del

valor “Bearer”, que permite al servidor conocer el tipo de acceso empleado por el

cliente, la cabecera “digitalSignature” donde se incluye una firma digital generada

por el personal autorizado, que permita dejar constancia de la operación que éste

va a realizar.

https://www.postman.com/

https://192.168.100.51/citizen/newCitizen


134

Imagen 58. Firma digital - Citizen Controller

1. Por último, se ha incluido en el cuerpo o body de la petición, el siguiente objeto

JSON, con todos los datos referentes al nuevo ciudadano que se desea registrar en

el sistema.

Imagen 59. Cuerpo petición - Citizen Controller

Finalmente, se envía la petición recién configurada, y si todo ha ido correctamente, el

servidor devolverá al cliente un código de confirmación 201, indicando que el proceso se

ha podido realizar correctamente y que el nuevo ciudadano ha sido dado de alta. Así, tal y

como se puede ver en la imagen inferior, el servidor también procede a devolver los datos

con los que el ciudadano ha sido dado de alta en el sistema.


135

Imagen 60. Resultado petición - Citizen Controller


136

4.2. Paciente (Patient)

Para el caso del controlador de pacientes, también se han desarrollado un total de cinco

nuevas peticiones API REST, las cuales se dividen nuevamente en dos peticiones del tipo

GET, que permiten conocer los datos de un paciente en concreto a partir de una serie de

parámetros o bien, obtener el listado completo de pacientes registrados en el sistema.

Además de estas dos peticiones del tipo GET, también se incluye una de los tipos

DELETE, POST y PUT.

Imagen 61. PatientController

En esta ocasión, se demostrará el funcionamiento de la petición GET que permite conocer

los datos concretos de un paciente. Para ello, tal y como se demostrará posteriormente, el

sistema necesita conocer su identificador como ciudadano (NIF, NIE o Pasaporte) y su

número identificativo como paciente (número seguridad social o similares). Por lo tanto,

ambos números deben ser únicos y deben coincidir para una misma persona física, en caso

contrario, el sistema rechazará la petición.

Para hacer uso de la petición REST, se vuelve a hacer uso de la variable “HTTPS

raspberry”, que como se ha mencionado durante el ejemplo anterior, tiene el valor

“https://192.168.100.51:8443”. Seguidamente, se indica que se desea utilizar el controlador

de paciente, y por último el recurso llamado “one”. Además, tal y como se puede ver en la

imagen inferior, el sistema requiere que incluya con la petición una cabecera llamada

“digitalSignature” con el contenido de la firma digital que se debe validar en el servidor.

https://192.168.100.51:8443/


137

Imagen 62. Firma digital - PatientController

Junto con la cabecera mencionada anteriormente, la petición también requiere que se

incluya en el cuerpo de la petición un objeto JSON con el identificador del ciudadano y de

la seguridad social, que como se ha mencionado anteriormente, ambos números deben

ofrecer como resultado una única persona. En caso contrario, el sistema rechazará la

petición.

Imagen 63. Cuerpo petición - PatientController

Con todos los datos requeridos por el sistema incluidos en la petición HTTPS, ya

estaremos en disposición de enviar la solicitud y verificar la respuesta recibida por parte

del servidor del sistema. Si toda la información incluída junto con la petición es correcta, el

sistema devolverá junto con un código HTTP 200, los datos personales de ese paciente en

particular, tal y como se puede ver en la imagen inferior:


138

Imagen 64. Resultado petición - PatientController

Por último, destacar que, en el campo llamado “digitalSignature” que se incluye dentro del

objeto JSON generado por el servidor a modo de respuesta, se incluye la firma digital del

último sanitario que ha realizado algún cambio sobre los datos del paciente o bien, ha

registrado al paciente en el sistema. Este hecho junto con un sistema propio de auditoría,

deja evidencias que permitan auditar el correcto desempeño de los usuarios del sistema, es

decir, malas praxis por parte de los sanitarios o acciones perjudiciales llevabas a cabo por

los administradores del sistema.


139

4.3. Administrador de Sistemas (System Administrator)

En lo referente al controlador de peticiones relacionadas con los administradores de

sistemas, para la primera versión del sistema desarrollado, se han incluido nuevamente

cinco peticiones HTTPS, que se componen de dos peticiones del tipo GET y una para el

resto de las peticiones desarrolladas (DELETE, POST y PUT).

Como se puede ver en la imagen inferior, al igual que con los anteriores dos controladores,

se ha incluido una pequeña documentación de Swagger, que permite a cualquier usuario

del sistema que pretenda utilizar esta interfaz de usuario, conocer el propósito de cada una

de las distintas peticiones.

Imagen 65. SystemAdministratorController.

En esta ocasión, se va a proceder a demostrar el correcto funcionamiento de la petición que

hace uso del método PUT, es decir, la petición del controlador destinada a actualizar

información de un administrador de sistemas.

Este procedimiento puede resultar más práctico de lo que en un primer momento se pudiera

llegar a pensar, entre otras posibilidades, la presente petición permite sin eliminar del

sistema a un administrador, bloquear su usuario para que éste no pueda realizar ninguna

acción en el sistema. Esta acción en particular se puede conseguir cambiando el valor del

parámetro “active” a NO. Automáticamente, el sistema desarrollado detectará antes de

procesar cualquier tipo de petición, que el usuario ya no tiene acceso al sistema, por lo que,

rechazará cualquier petición directamente.


140

Para hacer uso de este recurso del servicio REST, se deberá configurar la petición con el

método HTTP apropiado (PUT) junto con la URL correcta, siendo en este caso

“https://192.168.100.51:8443/administrators/updateAdministrator”. Junto a la petición, tal

y como se puede ver en la imagen inferior, se debe incluir una cabecera con la firma digital

de los datos que se van a actualizar en el servidor del administrador

Imagen 66. Firma digital - SystemAdministratorController

En el cuerpo del mensaje, se debe incluir un objeto en formato JSON como el que se

muestra a continuación, que permite al sistema detectar de manera inequívoca los campos a

actualizar de forma automática, reduciendo el tiempo necesario para actualizar los datos, ya

que, tan sólo se modifican aquellos que son necesarios. En este caso, tal y como se había

adelantado al inicio del presente apartado, se va a bloquear el acceso al sistema al

administrador de sistemas con ID “76262f21-7157-47f6-9e54-59635f34dcdd”.

https://192.168.100.51:8443/administrators/updateAdministrator


141

Imagen 67. Cuerpo petición - SystemAdministratorController

Si la petición ha sido enviada de manera correcta y se cumplen con todos los

requerimientos de seguridad definidos para el uso del recurso descrito, el servidor del

sistema devolverá una respuesta con código 200 y un objeto JSON con los datos

registrados para el administrador de sistemas para el que se han acaban de actualizar los

datos. Un ejemplo de este hecho, podría ser el objeto JSON mostrado en la imagen inferior.


142

Imagen 68. Resultado petición - SystemAdministratorController


143

4.4. Personal Sanitario (Health Personnel)

El sistema también dispone de un nuevo controlador encargado de atender las peticiones

relacionadas con el procesamiento de datos de los sanitarios registrados en el sistema. Al

igual que para los tres controladores anteriores, el sistema dispone de cinco recursos API

REST con los que consultar entre otros la información de un sanitario en concreto o de

todos aquellos que el sistema tiene constancia.

Nuevamente, para el controlador de las peticiones referentes a los sanitarios del sistema, se

ha incluido la suficiente documentación tanto a nivel de JavaDoc como de Swagger, con el

objetivo de permitir tanto a los usuarios como desarrolladores, hacer uso del servicio de

una manera sencilla y rápida.

Imagen 69. HealthPersonnelController

Para la demostración del funcionamiento del presente controlador, se va a mostrar cómo

también el sistema es capaz de mostrar de una manera estructurada el contenido de todos

los sanitarios registrados en el sistema. Destacar que, por el tamaño de la respuesta del

servidor no se va a proceder a mostrar la totalidad de esta, ya que, la respuesta generada

daría lugar a varias páginas del documento, y eso tampoco es lo que se pretende demostrar,

sino el correcto funcionamiento y las distintas capas de seguridad que el proyecto incluye

para proteger y securizar los datos. Aclarado lo anterior, como se va a hacer uso del recurso

que ofrece toda la información de los sanitarios registrados, la URL empleada será

“https://192.168.100.51:8443/administrators/all”. Además, el método HTTP utilizado será

del tipo GET tal y como se podría prever. Por último, al igual que con anteriores peticiones

realizadas, se debe enviar una cabecera con el contenido de una firma digital que permita al

sistema dejar constancia y veracidad de la acción solicitada por el usuario.

https://192.168.100.51:8443/administrators/updateAdministrator


144

Imagen 70. Resultado petición - HealthPersonnelController

Tal y como se puede ver en la imagen anterior, con una misma petición HTTPS se ha

conseguido obtener los datos de los sanitarios registrados en el sistema. Nuevamente


145

recalcar que por motivos de tamaño de la respuesta no se ha podido visualizar el contenido

total de la misma, pero sí que mediante la imagen anterior se puede apreciar como en una

misma respuesta se ha devuelto la información de un enfermero y de un trabajador social,

con los siguientes nombres de usuario: Enfermero - TFM, Trabajador social - TFM.

4.4.1. Médico (Doctor)

A continuación, se procede a detallar y exponer el funcionamiento de una de las cinco

peticiones HTTPS, que el controlador destinado a manejar y procesar información de los

médicos dispone. Al igual que con los anteriores casos, el controlador dispone de dos

peticiones del tipo GET y una de los tipos: DELETE, POST y PUT.

Todo esto se puede visualizar de una manera mucho más rápida e intuitiva para cualquier

usuario a través de la interfaz web de Swagger, gracias al trabajo realizado para

documentar cada una de las peticiones.

Imagen 71. DoctorController

En esta ocasión se demostrará el correcto funcionamiento del proceso referente al registro

y activación de la cuenta de un nuevo médico en el sistema, ya que, presenta algunas

diferencias con el proceso de registro de un sanitario. La principal diferencia entre ambos

casos radica en que los médicos tendrán acceso al sistema, mientras que los ciudadanos o

pacientes no. Con ello aclarado, vamos a ver el proceso de creación de un nuevo médico.

En esta ocasión, debido a que es un proceso de registro el método a utilizar será POST y la

URL “https://192.168.100.51:8443/doctor/newDoctor/?userID={value}”. Tal y como se

https://192.168.100.51:8443/doctor/newDoctor/?userID=%7Bvalue%7D


146

puede deducir tanto de la URL anterior, como de la que aparece en la imagen inferior, el

sistema requiere de un identificador de usuario que va a realizar el alta, como parámetro

necesario para el control del personal habilitado para efectuar ese tipo de operación.

Al mismo tiempo, se dará de alta al nuevo médico en el servicio Keycloak, con el objetivo

de conocer su identificador como usuario del sistema, por ser un valor necesario que incluir

en el cuerpo de la petición.

Además, por seguridad, el sistema requiere el paso de una firma digital a través de una

cabecera especialmente destinada para ello, tal y como se puede ver en la imagen inferior:

Imagen 72. Firma digital - DoctorController

Por último, el recurso requiere de un cuerpo en formato JSON con los datos

correspondientes al médico que se quiere registrar en el sistema, siendo un ejemplo de este

objeto el que se muestra a continuación:


147

Imagen 73. Cuerpo petición - DoctorController

Finalmente, ya se podrá enviar la petición, que devolverá un código 201 indicando que

todo ha ido correctamente y que el nuevo médico ha sido registrado en el sistema. Destacar

que, este proceso es algo más lento que los anteriores debido a que el sistema debe generar

claves RSA de 4096 bits para el nuevo usuario, que en un futuro le permitan realizar firmas

digitales. Debido a que la clave privada no es almacenada en el servidor por motivos

obvios, la presente operación sólo puede ejecutarse por personal habilitado para ello, y está

disponible desde determinadas direcciones IP indicadas previamente, ya que, junto con los

datos de confirmación registrados en el sistema, se incluye un parámetro adicional que es

la clave privada del usuario. De esta manera, el personal habilitado para estas operaciones

puede obtener la clave privada del usuario y almacenarla en los dispositivos móviles que

vaya a utilizar dicho usuario.


148

Imagen 74. Resultado petición - DoctorController

Con esto lo que se consigue es evitar almacenar claves privadas en el sistema. Y como se

ha dicho recalcado anteriormente, dada la importancia de operaciones como la presente,

existen medidas de seguridad adicionales que ofrecen mayores garantías durante el

proceso. Además, todo el proceso al igual que el resto, queda debidamente registrado para

poder conocer de manera sencilla el momento, lugar y usuario que ha llevado a cabo cada

acción.


149

4.4.2. Enfermero (Nurse)

Como se puede ver en la imagen inferior obtenida de la interfaz web de Swagger, el

controlador de esta primera versión encargado de procesar las peticiones relacionadas con

los enfermeros del sistema también tiene implementadas cinco peticiones HTTPS, siendo

estás las descritas en la imagen inferior.

Imagen 75. NurseController

En esta ocasión se mostrará el correcto funcionamiento del recurso que permite obtener la

información concreta de un enfermero o enfermera registrado en el sistema. Para ello, será

necesario conocer el identificador como profesional que dispone dicho usuario en el

sistema. Aclarado lo anterior, para hacer uso del recurso necesitaremos configurar la

petición nuevamente al tipo GET y establecer la URL adecuada, siendo ésta de acuerdo a lo

indicado en la interfaz de Swagger, la siguiente:

“https://192.168.100.51:8443/nurse/one?id={value}”. El parámetro que se debe pasar por

la URL, será el identificador del sanitario del que se desea obtener la información, tal y

como se ha indicado previamente.

Por último, antes de enviar la solicitud, al igual que con anteriores peticiones descritas, será

necesario incluir una cabecera con el valor de la firma digital, que permita verificar que la

solicitud se ha realizado por el usuario que se indica en el JWT adjuntado junto con la

petición.

Si todos los datos incluidos son correctos, el sistema devolverá un código 200, junto con

los datos asociados al enfermero o enfermera con ese identificador, tal y como se puede ver

en la siguiente imagen:

https://192.168.100.51:8443/nurse/one?id=%7Bvalue%7D


150

Imagen 76. Resultado petición - NurseController


151

4.4.3. Trabajador Social (Social Worker)

El controlador asociado a los trabajadores sociales se trata del último de los cuatro

controladores diseñados e implementados para la presente versión del sistema objetivo del

presente proyecto final de máster. Al igual que para los anteriores controladores

relacionados con el personal sanitario con acceso al sistema, éste admite cinco peticiones

HTTPS, siendo dos de ellas del tipo GET y una de los tipos DELETE, POST y PUT.

Imagen 77. SocialWorkerController

Para concluir con los controladores relacionados con el personal sanitario, se va a mostrar

nuevamente el proceso empleado por el sistema para registrar un nuevo trabajador social,

que como se podrá comprobar es muy similar al de los médicos. Con esto lo que se quiere

demostrar es que se ha dado la misma importancia a los registros de los médicos que a los

trabajadores sociales, y esto por motivos de seguridad y en evitación de accesos ilegítimos

al sistema.

Dado que se trata nuevamente de una petición del tipo POST, se debe configurar el cliente

utilizado para enviar este tipo de petición. En cuanto a la URL que se debe emplear para

acceder correctamente al recurso REST implementado es

“https://192.168.100.51:8443/socialWorker/newSocialWorker/?userID={value}”, siendo el

valor del parámetro “userID” el identificador que el usuario que va a hacer la petición

dispone en Keycloak. De esta manera, el sistema puede añadir una capa de seguridad

adicional para verificar que el usuario es legítimo y puede realizar dicha petición al

sistema..

https://192.168.100.51:8443/doctor/newDoctor/?userID=%7Bvalue%7D


152

Imagen 78. Firma digital - SocialWorkerController

Al igual que con las anteriores peticiones, el sistema requiere de una firma digital que debe

ser incluida mediante la cabecera con nombre “digitalSignature”. Con todos los datos

correctamente incluídos, tan sólo restará por añadir en el cuerpo de la petición, un objeto

JSON con los datos del nuevo trabajador social que se quiera registrar en el sistema.

Imagen 79. Cuerpo petición - SocialWorkerController

Como se puede ver en la imagen anterior, el objeto JSON enviado al sistema no contiene

una clave pública RSA válida, pero esto no es problema, ya que, el sistema es conocedor


153

de que ese dato en particular no puede ser conocido hasta que el usuario no ha sido

registrado y se proceda a generar su pareja de claves RSA de 4096 bits. Pese a que su

contenido sea irrelevante para la petición, su inclusión en el objeto JSON al igual que con

el resto de atributos resulta fundamental, así el controlador lo primero que hace antes de

procesar la petición es convertir de manera automática el objeto JSON a un objeto Java del

tipo “SocialWorker”. En caso de no incluirse, el sistema de Spring Boot no sabrá convertir

correctamente el objeto, lo que provocará que la petición no se llegue a procesar y se

devuelva un error.

En este caso, como todos los datos han sido correctamente indicados, el servidor devuelve

una respuesta con código 201 indicando que el proceso se ha realizado con éxito. Además,

al igual que se ha podido mostrar durante el procedimiento de registro de un nuevo médico,

se incluye también la clave pública y privada del nuevo trabajador social, para que ésta

pueda ser correctamente almacenada por el personal habilitado en el dispositivo o

dispositivos móviles, que el sanitario vaya a utilizar. Resaltar nuevamente que la clave

privada no es almacenada en el servidor y por lo tanto, no es enviada en ningún otro

momento por el servidor.

En caso de extraviar o perder el anonimato de la clave privada del usuario, un usuario

administrador, debería deshabilitar la clave actual y generar una nueva al sanitario, para

que éste pueda seguir utilizando el sistema con normalidad.


154

Imagen 80. Resultado petición - SocialWorkerController


155

4.5. Dispositivo (Device)

Con el objetivo de simplificar la administración de los distintos dispositivos móviles y fijos

que los usuarios pueden utilizar para hacer uso del sistema, se ha incluído otro nuevo

controlador, que para esta primera versión del servicio incluye un total de siete peticiones

HTTPS, siendo cuatro de ellas del tipo GET, tal y como se puede comprobar en la imagen

inferior.

Imagen 81. DeviceController

Con la inclusión de este nuevo controlador, se pretende que el acceso al sistema por parte

de los usuarios sea fiable, al mismo tiempo que los administradores puedan realizar las

tareas cotidianas relacionadas con los dispositivos de una manera sencilla y eficaz.

Aclarado lo anterior, se va a proceder a mostrar los pasos necesarios para consultar los

datos de un terminal, que tiene asociada una clave pública determinada, es decir, se quieren

conocer los datos de un terminal a partir de una clave RSA, que a su vez está vinculada a

un único usuario del sistema, como se verá al final.

Para hacer uso de esta petición necesitamos realizar la siguiente configuración:

● Configurar el cliente para enviar una petición del tipo GET.

● Fijar la URL a la que se debe realizar la petición, siendo en este caso:

“https://192.168.100.51:8443/device/byPublicKey”.

● Introducir la correspondiente firma digital en la cabecera destinada para ello.

https://192.168.100.51:8443/device/byPublicKey


156

● Enviar en el cuerpo de la petición el valor de la clave pública RSA que se quiere

utilizar para obtener el dispositivo o dispositivos, asociados a ella.

Todos estos detalles se pueden observar mediante las siguientes dos imágenes:

Imagen 82. Firma digital – DeviceController

Imagen 83. Cuerpo petición - DeviceController

Finalmente, tan sólo nos quedará enviar la petición y esperar el resultado, si los datos son

correctos, debe devolver un código 200 junto con los datos del terminal asociado a la clave

pública del usuario en formato JSON al igual que el resto de las respuestas del sistema.


157

Imagen 84. Resultado petición - DeviceController


158

4.6. Historial Médico (History)

Uno de los controladores más relevantes para el correcto funcionamiento global del sistema

es el referente a los historiales médicos de los pacientes, ya que, se debe recordar que el

objetivo principal del proyecto es permitir el acceso de manera segura a los datos médicos

de un paciente, y ello implica de manera directa al historial clínico.

Por ello, y con el objetivo de intentar suplir las necesidades básicas de los sanitarios

encargados de realizar visitas a pacientes a domicilio, para esta primera versión del

servicio, se han implementado cinco peticiones REST que se pueden ver de manera gráfica

en la imagen inferior.

Imagen 85. HistoryController

En esta ocasión se va a proceder a demostrar el correcto funcionamiento del recurso REST

que permitiría a un sanitario, acceder de manera fiable a los datos médicos de un paciente

realizados en un día determinado, desde el propio domicilio del paciente utilizando su

dispositivo habilitado y asignado para ello.

Para hacer uso de este recurso, el futuro cliente del sistema con el que se pretende facilitar

la realización y visualización de las distintas peticiones y respuestas, por parte de los

usuarios, debería realizar una petición HTTPS del tipo GET con las siguientes

particularidades:


159


“https://192.168.100.51:8443/history/one”.

● Enviar en el cuerpo de la petición un objeto del tipo JSON con tres atributos con

los siguientes nombres: “idCitizen”, “historyDate” y “digitalSignature”.

Imagen 86. Cuerpo petición - HistoryController

Si los valores introducidos son correctos y se han encontrado resultados, el servidor

devolverá una petición como la que se muestra a continuación, donde como se puede ver,

aparecen todos los datos referentes a la entrada en el registro médico del paciente con DNI

74016303A realizadas el día 15 de Junio del 2021.



160

Imagen 87. Resultado petición - HistoryController


161

4.7. Registro de Acceso (Access Register)

Dada la alta sensibilidad de los datos manejados por el sistema y sus usuarios, resulta

fundamental el dejar constancia de cualquier tipo de acción que ocurre en el sistema. Por

ello, ante cualquier petición REST disponible, incluye un procedimiento que deja

constancia de manera clara e inequívoca de la acción realizada por cada usuario.

Con esto se pretende poder determinar, por ejemplo, la intervención de cada usuario del

sistema en el expediente del paciente.

Por ello, y para facilitar el acceso a todo este tipo de información, se ha desarrollado un

controlador en específico que permite visualizar aquella información que se desee. En

particular este controlador incluye cuatro peticiones GET mediante las cuales se puede

desde visualizar toda la información de manera “bruta”, o realizar una serie de filtrados con

los que obtener de una manera más rápida la información deseada.

Imagen 88. AccessRegisterController

Por ello, en la presente demostración, se puede verificar cómo se puede conocer de forma

sencilla todas las entradas, lecturas y modificaciones que un sanitario ha realizado sobre el

historial médico de un paciente. Para ello, el cliente del sistema debería realizar una

petición con la siguiente estructura:



“https://192.168.100.51:8443/accessRegistry/byHealthPersonnelAndPatient”.



162

● Enviar en el cuerpo de la petición un objeto JSON con los siguientes campos:

“idCitizen”, “idSocialSecurity”, “idHealthPersonnel” y “digitalSignature”.

A modo de resumen, se incluye la imagen inferior, con un ejemplo realizado sobre este

mismo recurso utilizando el software Postman.

Imagen 89. Cuerpo petición - AccessRegistryController

Si la petición va como se espera de ella, el servidor devolverá un código 200 y un objeto

JSON con todos los datos encontrados que coinciden con los parámetros proporcionados,

tal y como se puede ver en la imagen inferior. En este caso se está buscando un paciente

con identificador de seguridad social “11111” y DNI 74016303A, que tenga algún registro

generado, generado, leído o modificado por el sanitario con ID 10, que produce la

respuesta mostrada en la imagen inferior, en la que se aprecia que existe al menos un

registro del historial generado (valor CREATED) por el sanitario con ID 10.


163

Imagen 90. Resultado petición - AccessRegisterController


164

4.8. Auditoría (Audit)

Los usuarios administradores son una pieza fundamental en el correcto funcionamiento del

sistema, de ellos depende la aplicación de determinados procedimientos como los descritos

anteriormente, que por motivos de seguridad están restringidos a tan sólo usuarios con sus

privilegios. Además del registro de nuevos usuarios (sanitarios y otros administradores),

estos usuarios con un elevado número de privilegios tienen también disponibles acciones

como la generación o reemplazo de claves RSA o el bloqueo de ciertos usuarios, para

impedir el acceso al sistema a determinadas personas.

Por todo lo mencionado anteriormente y otras peticiones REST que tienen disponibles y no

han sido mencionadas, resulta crucial registrar las acciones que también llevan a cabo los

administradores. Para ello, se ha generado un nuevo controlador que permite mediante unas

simples peticiones HTTPS, visualizar estos datos.

Tal y como se puede ver en la imagen inferior, este controlador al igual que el expuesto

anteriormente está compuesto por cuatro peticiones, siendo todas ellas del tipo GET.

Además, de acuerdo con lo expuesto en la documentación realizada mediante el entorno

Swagger, se puede ver que el controlador puede devolver todos los registros realizados, los

realizados en un día determinado, los guardan relación con un paciente o bien, registros

producidos por las acciones de un administrador de sistemas en particular.

Imagen 91. AuditController


165

Se va a proceder a exponer el correcto funcionamiento del controlador mediante el uso de

la petición API REST, que devuelve todos los registros en los que se ha visto relacionado

un paciente en particular.

Para realizar la petición se deberá configurar el cliente utilizado de la siguiente manera:



“https://192.168.100.51:8443/audit/byPatient”.

● Enviar en el cuerpo de la petición un objeto JSON con los siguientes campos:

“idCitizen”, “idSocialSecurity”, y “digitalSignature”. Siendo el último campo el

valor de la firma digital de los datos que van a ser enviados.

Imagen 92. Cuerpo petición - AuditController

Configurado el cliente con todos los datos correctamente, ya nos encontraremos en

disposición de realizar el envío de la petición, y de haber introducido todos los datos de

una manera correcta, el servidor devolverá un código 200 junto con un objeto JSON con

todos los datos solicitados. Un ejemplo de la respuesta generada por este método del

controlador AuditController, sería el expuesto en las siguientes imágenes.



166

Imagen 93. Resultado petición 1 - AuditController


167

Imagen 94. Resultado petición 2 - AuditController


168

Como se puede ver en la respuesta generada por el servicio REST, se ha registrado que el

administrador de sistemas con identificador 1, ha procedido a leer un registro del historial

médico del paciente con DNI 74016303A. En concreto, el administrador ha accedido a los

datos del registro llevado a cabo el 15 de junio del 2021 a las 13:47:26 hora peninsular.

De esta manera, se puede ver claramente que el sistema deja siempre constancia de las

acciones realizadas por administradores de sistemas, pudiendo auditar en un futuro si algún

usuario ha llevado a cabo acciones perjudiciales contra el sistema o sus usuarios de manera

intencionada.


169

4.9. Clave Pública-Privada (Private-Public Key)

Como se ha podido ir viendo a lo largo de los distintos ejemplos realizados durante el

presente apartado (Resultados), las peticiones que se envían al sistema requieren de una

firma digital. Dicha firma digital es necesaria para que el sistema pueda verificar los

siguientes aspectos fundamentales en cada petición que recibe:

1. Permite asegurar que la petición REST que el servidor ha recibido es idéntica a la

que el cliente envió desde el otro extremo de la comunicación.

2. Se puede comprobar si efectivamente la firma digital ha sido generada utilizando la

clave privada del mismo usuario propietario del JWT empleado para autenticarse

contra el servicio.

Como se puede ver, el procedimiento de generación y validación de firmas digitales se

trata de un proceso común y sumamente repetido, con el claro objetivo de dotar de una

mayor seguridad al sistema. Por ello, y dado que no se disponía de ningún cliente con el

que realizar las firmas digitales que el sistema debía validar, se decidió añadir un noveno

controlador, para calcular y validar las firmas digitales, antes de que estas fueran enviadas

junto con una petición de las expuestas anteriormente.

Este noveno y último controlador, ofrece dos recursos GET con los que calcular y verificar

una firma digital.

Imagen 95. Public and Private Key Manager Encription Controller

En esta ocasión y dada la alta importancia que ambos recursos han tenido durante el

desarrollo del servicio desarrollado, se va a exponer el funcionamiento de ambos.

En primer lugar, procederemos a analizar el funcionamiento del recurso que calcula una

firma digital. Como se ha indicado anteriormente, se trata de un recurso del tipo GET y que

requiere de un objeto JSON en el cuerpo de la petición. Este objeto debe tener como


170

mínimo un atributo que sea la clave privada a utilizar, junto con el resto de los atributos

que se quieran utilizar para calcular la firma digital utilizando el algoritmo RSA.

Tal y como se puede ver en la imagen inferior, se ha proporcionado la clave privada, junto

con un DNI y una fecha, para que estos dos últimos datos puedan ser utilizados para

calcular el resultado deseado. Cuando se envía la petición, el servidor responderá con un

código HTTP 200 y un objeto JSON con dos atributos (“result”, “error”).

Imagen 96. Cuerpo petición 1 - Public and Private Key Manager Encription Controller


171

Imagen 97. Resultado petición 1 - Public and Private Key Manager Encription Controller

Una vez se dispone de la firma digital deseada, ya se puede utilizar para ser enviada junto a

alguna petición HTTPS de las analizadas anteriormente.

Expuesto el procedimiento anterior,se va a proceder a analizar el funcionamiento del

proceso que realiza el sistema para validar una firma digital.

Para validar una firma digital el sistema requiere de tres datos principales que son: clave

pública a emplear, firma digital a validar y un listado de los valores utilizados para calcular

dicha firma digital. Todos estos datos deben ser enviados en el cuerpo de la petición

haciendo uso de un objeto JSON como el mostrado en la imagen inferior.

Por último, una vez la petición ha sido verificada por el servidor, se devuelve nuevamente

un objeto JSON con los mismos atributos que en el caso anterior (“result”, “error”). Si la

firma se ha podido validar correctamente, como es el caso del ejemplo de la siguiente

imagen, el atributo “result” estará igualado a verdadero y no se mostrarán errores. Esto

querrá decir que la firma digital es correcta, y que fue generada utilizando la clave privada

asociada a la clave pública utilizada para esta verificación.


172

Imagen 98. Cuerpo petición 2 - Public and Private Key Manager Encription Controller

En cambio, si se vuelve a repetir pero alterando ligeramente la firma digital enviada, se

podrá comprobar cómo el resultado en esta ocasión cambia, y nos informa que no se ha

podido validar correctamente la firma digital, algo de esperar, ya que, el valor de la nueva

firma enviada es incorrecto.


173

Imagen 99. Resultado petición 2 - Public and Private Key Manager Encription Controller


174

5. Conclusiones

En primer lugar, se procederá a analizar los resultados obtenidos al finalizar el presente proyecto de

final de máster en la Universidad de Alicante, explicando de manera detallada cada uno de los

principales objetivos que se querían alcanzar al inicio de este. Además, también se expondrán los

principales problemas o dificultades encontrados durante todo el desarrollo del proyecto.

Asimismo, se determinan las posibles líneas futuras a llevar a cabo en posteriores versiones del

sistema, pero antes de todo ello, aclarar que, para la realización del presente proyecto de final de

máster, todas las asignaturas cursadas durante el curso académico han contribuido en mayor o

menor medida a conseguir el objetivo propuesto al inicio, pero quizá las que han tenido una mayor

relevancia dada la temática del proyecto han sido:

○ Protección de la Información. Ha proporcionado los conocimientos necesarios para

manejar, tratar y procesar correctamente información cifrada.

○ Desarrollo de Aplicaciones Seguras. Ha establecido las bases para la realización de

un diseño y desarrollo de software seguros que permitan evitar la introducción de

vulnerabilidades durante el proyecto.

○ Seguridad en los Sistemas Operativos. Ha otorgado mayores conocimientos en lo

referente a la administración de servicios en entornos Linux, que han permitido

definir y configurar de manera adecuada la infraestructura levantada.

○ Seguridad en Aplicaciones y Bases de datos. Ha dotado de las técnicas de

desarrollo de software seguro, que evite la introducción de vulnerabilidades como

la inyección de código SQL.

○ Hacking Ético y Contramedidas. Ha demostrado la necesidad de aplicar medidas

de seguridad a nivel de infraestructura con el objetivo de dotar de una mayor

seguridad al sistema desarrollado.


175

5.1. Análisis de los resultados obtenidos

El principal objetivo del proyecto era crear un sistema que permitiera al personal sanitario

(Médicos, Enfermeros, Trabajadores Sociales …) gestionar las distintas visitas, que

muchos de ellos deben realizar a pacientes que, por cualquier patología, les es imposible

desplazarse a su centro de salud más cercano.

Por ello, se propone un sistema informático que permita acceder de manera remota, desde

cualquier punto de la geografía española, a los datos de los pacientes. Todo ello, teniendo

siempre como una máxima la seguridad, dada la alta sensibilidad de los datos tratados por

el sistema. Por ese motivo, el sistema en todo momento garantiza la confidencialidad,

integridad y disponibilidad de los datos, con el objetivo de proporcionar un sistema robusto

y fiable, que permita tan sólo a los usuarios legítimos y autorizados del sistema conocer los

datos solicitados.

De esta manera, se pretende mejorar las condiciones de miles de sanitarios de toda España,

y a la vez disponer de un sistema más eficiente, tanto en el tratamiento de la información

como en el acceso a la misma, lo que puede repercutir en el sistema en general, en cuanto

se puede realizar un mejor uso de los medios disponibles en la actualidad.

Así, en el sistema médico desarrollado, los sanitarios autorizados podrán además de

acceder a los datos médicos de los pacientes, repercutiendo esto directamente en la calidad

de la atención, incluir nuevos registros en el historial médico del paciente al que acaban de

visitar, proporcionando mayor fiabilidad a la información que se transcribe, en cuanto

disminuye el riesgo de cometer errores y a la vez supone una mejora laboral, en cuanto

evita tener que volcar todos las anotaciones que se hayan realizado en cada uno de los

expedientes al final de la jornada laboral de un sanitario. Pero además permitiría un uso

más eficiente de los recursos en cuanto podrían evitarse segundas visitas o retrasos en las

ya previstas.

Para conseguir desarrollar el sistema necesario, se ha hecho uso de una infraestructura

basada en microservicios, y se ha logrado mediante el uso de 5 contenedores Docker con

distintos fines, tal y como se ha mencionado con un amplio grado de detalle en dicha

sección del documento. Gracias al uso de una arquitectura de microservicios junto con

Docker, se ha podido separar y aislar los cinco elementos fundamentales del sistema que

son: servicio de conexiones VPN (WireGuard), servicio de base de datos (MariaDB),

servidor de autenticación y autorización de usuarios (Keycloak), servicio de

monitorización del sistema (NetData) y el encargado de ejecutar los procesos asociados al


176

desarrollo REST realizado bajo Spring Boot (Alpine). Además, dada la naturaleza sensible

de los datos, toda comunicación incluida entre contenedores va debidamente cifrada

mediante el uso de certificados SSL, a la que se le añade una capa adicional para las

conexiones remotas al sistema. Así, las conexiones realizadas por los sanitarios

desplazados a los domicilios de los pacientes se realizan dentro de un túnel VPN con su

correspondiente capa de cifrado adicional.

Además, el sistema ha sido debidamente protegido mediante una configuración de Firewall

específica, que junto con una protección por software realizada en cada uno de los distintos

servicios que componen el sistema, permite garantizar la disponibilidad de los mismos tan

sólo a los usuarios autorizados. Para ello, se han definido dos subredes dentro de la

infraestructura utilizada, siendo una de ellas física, mientras que la otra es virtual, es decir,

los equipos físicos de la red hacen uso de la subred preexistente, mientras que, los

dispositivos remotos hacen uso de una subred distinta.

De esta manera, se puede realizar una configuración mucho más específica y sencilla,

evitando que, por ejemplo, los dispositivos remotos puedan acceder al servicio de

monitorización. De la misma manera, el servicio Keycloak tan sólo puede ser utilizado

administrado por los equipos de la red física, mientras que, los equipos de la red virtual

(conexiones VPN) tan sólo pueden realizar tareas de autenticación.

Todo el sistema junto con la infraestructura necesaria ha sido configurado desde cero, por

lo que, cada elemento ha sido cuidadosamente adaptado para una mayor seguridad.

También destacar el alto grado de optimización realizado sobre cada uno de los

componentes del sistema, ya que, aparte de verificar el correcto funcionamiento del mismo,

se ha obtenido una gran experiencia de usuario, algo especialmente destacable si se tiene

en cuenta que el servidor empleado ha sido una Raspberry Pi 4, que cuenta con una

potencia bastante limitada, y que el lenguaje de programación Java junto a Spring Boot no

ofrece el mismo rendimiento que aplicaciones similares desarrolladas en lenguajes como C

o C++.


177

5.2. Problemas encontrados durante el desarrollo

Tal y como se ha venido exponiendo a lo largo del presente documento, el proyecto

desarrollado presenta una alta complejidad, al mismo tiempo que, se trata de un proyecto

vanguardista que viene a cubrir ciertas necesidades que determinados sanitarios a día de

hoy requieren. Todo ello, combinado con el uso de muchas y diferentes tecnologías, que

me eran totalmente desconocidas antes de iniciar el proyecto, han hecho que se haya

convertido en un estudio realmente laborioso al mismo tiempo que enriquecedor.

Como se puede deducir, se trata de un proyecto que ha requerido de una enorme lista de

tareas para el correcto desarrollo de cada uno de los elementos que constituyen el sistema.

Durante el tiempo de realización del presente trabajo, se han encontrado multitud de

problemas y dificultades, estando la mayoría de ellas relacionadas con una falta de

experiencia previa en las tecnologías utilizadas.

Se debe destacar la curva de aprendizaje requerida para poder aprovechar al máximo cada

una de las tecnologías empleadas, siendo bastante elevadas en algunos casos, como por

ejemplo con Spring. Es cierto que, el framework empleado ofrece multitud de ventajas a la

hora de desarrollar un proyecto de gran envergadura como el presente, ya que, dota de una

gran capa de abstracción, eliminando y reduciendo de manera considerable problemas

comunes durante cualquier desarrollo software. Esto al mismo tiempo es un “arma de

doble filo”, ya que, un grado tan alto de abstracción implica conocer muy bien el

funcionamiento interno del framework utilizado, si se desea entender con detalle el

comportamiento del sistema (“under the hood”). Por lo tanto, comenzar a utilizar un

framework nuevo como Spring, da lugar a situaciones en las que no se sepa entender el

origen de un error o problema encontrado. A todo lo mencionado anteriormente, se debe

tener en cuenta que no sólo se ha utilizado la base del proyecto Spring, sino también

algunos de sus subproyectos como Spring Boot o Spring Security, lo que ha llevado a que

el aprendizaje haya sido muy prolijo.

Un gran problema encontrado ha sido la necesidad de levantar y configurar desde cero la

infraestructura necesaria para una correcta ejecución del sistema, si bien es cierto que es

algo que se había venido practicando durante el grado de Ingeniería Informática y en el

presente máster, nunca me había visto en la necesidad de enfrentarme a una situación real,

que siempre presenta retos nuevos que un entorno más limitado como puede ser una

práctica de la Universidad.


178

Otro gran reto ha sido el planificar y diseñar todas las capas de seguridad que el sistema

incluye, con las que se espera que el sistema sea lo más robusto y fiable posible. Se debe

recordar que el sistema incluye una estrategia en profundidad, en la que se han aplicado

diversas capas de seguridad en cada uno de los elementos, tanto a nivel de infraestructura

como software. Por ejemplo, a nivel de seguridad perimetral existe una configuración de

cortafuegos específicamente desarrollada para suplir tan sólo los requerimientos del

sistema y ninguno más, limitando así el rango de ataque de un ciberdelincuente. Asimismo,

tal y como se ha venido destacando hasta el momento cualquier comunicación, por muy

segura que se considere, al viajar dentro de la misma red, se vuelve en cierto modo

vulnerable, por lo que siempre viaja cifrada. Y en cambio, la información que va a circular

por fuera de la red privada recibe una capa adicional de cifrado (VPN).

Por último, y para concluir con el presente subapartado, destacar el esfuerzo que ha

supuesto trabajar con unos recursos tan limitados, como una Raspberry Pi, teniendo en

cuenta la elevada cantidad de procesos llevados a cabo de manera simultánea por el equipo.


179

5.3. Posibles líneas futuras

Uno de los factores más determinantes para que un sistema sea atractivo para su uso en un

entorno real como el propuesto, es que además de ser seguro y robusto, también sea

práctico, porque de nada sirve que un sistema sea hiper seguro si su uso es extremadamente

difícil, ya que, se convertiría al instante en un sistema prácticamente inútil.

Por ello, a continuación, se propone un pequeño listado con algunas líneas futuras que se

podrían llevar a cabo con el objetivo de mejorar aún más el sistema:

1. Desplegar el sistema en una infraestructura en la nube, lo que proveería al sistema

de manera casi automática de ciertos elementos de seguridad adicionales, como

protección ante ataques de denegación de servicio, contra los que el sistema actual

no dispone de elementos extremadamente robustos.

2. Al desplegar el sistema en un entorno cloud, se podría hacer uso de más recursos

hardware cuando estos fueran necesarios, es decir, se podría hacer uso de un

cluster dinámico13 con balanceo de carga, permitiendo al sistema una mejor

estabilidad y escalabilidad.

3. Haciendo uso de una mejor infraestructura, también se podría disponer de un o

múltiples WAF (Web Application Firewall) con los que asegurar en mejor medida

las distintas conexiones que el servidor recibe.

4. Uso de tecnologías como Kubernetes con las que también ajustar de manera

dinámica el uso de contenedores necesarios para satisfacer la demanda en cada

momento.

5. A medida que crezca el sistema, podría resultar que un modelo de base de datos

SQL llegara a ser contraproducente en términos de rendimiento. Por ello, la

migración a modelos de datos NoSQL a través de gestores de bases de datos como

MongoDB, podría ser una actualización a tener en cuenta.

6. Modificar el sistema de autenticación a un sistema mediante datos biométricos

como huella dactilar. Otro mecanismo perfectamente válido sería una correcta

implementación mediante reconocimiento facial, que además de acelerar el

proceso de autenticación lo convertiría en mucho más fiable.

13 Ver en el glosario


180

6. Referencias

[1] JETBRAINS, «Jetbrains.com,» [En línea]. Available: https://www.jetbrains.com/es-es/idea/.

[2] Oracle, «Oracle.com,» [En línea]. Available:

https://www.oracle.com/es/java/technologies/javase/javase-jdk8-downloads.html.

[3] J. v. Zyl, «Wikipedia.com,» 14 Junio 2021. [En línea]. Available:

https://es.wikipedia.org/wiki/Maven.

[4] A. Becker, «Wikipedia.com,» 31 Julio 2021. [En línea]. Available:

https://es.wikipedia.org/wiki/HeidiSQL.

[5] Postman, Inc., «Postman.com,» [En línea]. Available: https://www.postman.com/.

[6] «Wikipedia.com,» 15 Julio 2021. [En línea]. Available: https://es.wikipedia.org/wiki/GitHub.

[7] Microsoft, «Microsoft.com,» [En línea]. Available: https://www.microsoft.com/es-

ww/microsoft-365/visio/flowchart-software.

[8] Spring, «Spring.io,» [En línea]. Available: https://spring.io/why-spring.

[9] SpringSource, «Wikipedia,» 11 Agosto 2021. [En línea]. Available:

https://es.wikipedia.org/wiki/Spring_Framework.

[10] «Wikipedia.com,» 13 Junio 2021. [En línea]. Available:

https://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_aspectos.

[11] «Wikipedia.com,» 17 Junio 2021. [En línea]. Available:

https://es.wikipedia.org/wiki/Modelo%E2%80%93vista%E2%80%93controlador.

[12] «Wikipedia.com,» 26 Mayo 2021. [En línea]. Available:

https://es.wikipedia.org/wiki/Pruebas_de_software.

[13] «Spring.io,» [En línea]. Available: https://spring.io/projects/spring-boot.

[14] «Spring.io,» [En línea]. Available: https://spring.io/projects/spring-data.


181

[15] «Spring.io,» [En línea]. Available: https://spring.io/guides/topicals/spring-security-

architecture/.

[16] «Wikipedia.com,» 30 Octubre 2020. [En línea]. Available:

https://es.wikipedia.org/wiki/HATEOAS.

[17] «Ionos.es,» [En línea]. Available: https://www.ionos.es/digitalguide/paginas-web/desarrollo-

web/hateoas-que-es-y-cual-es-su-funcion-en-las-api-rest/.

[18] «Digicert.com,» [En línea]. Available: https://www.digicert.com/es/ssl-certificate/.

[19] «Tutorialsmate.com,» [En línea]. Available: https://www.tutorialsmate.com/2020/07/http-vs-

https.html.

[20] «Wikipedia.com,» 19 Agosto 2021. [En línea]. Available:

https://es.wikipedia.org/wiki/RSA#:~:text=Las%20claves%20RSA%20son%20normalmente,

el%20algoritmo%20RSA%20es%20seguro..

[21] P. d. l. I. -. A. M. C. U. d. Alicante, 2021.

[22] «JWT.io,» [En línea]. Available: https://jwt.io/introduction.

[23] «Openid.net,» [En línea]. Available: https://openid.net/connect/.

[24] «Wikipedia.com,» [En línea]. Available: https://es.wikipedia.org/wiki/OpenID.

[25] «OAuth.net,» [En línea]. Available: https://oauth.net/2/.

[26] «Okta.com,» [En línea]. Available: https://developer.okta.com/blog/2018/06/29/what-is-the-

oauth2-password-grant.

[27] «Openwebinars.net,» [En línea]. Available: https://openwebinars.net/blog/que-es-oauth2/.

[28] «Dockerlabs.collabnix.com,» [En línea]. Available:

https://dockerlabs.collabnix.com/beginners/docker/docker-vs-container.html.

[29] «Redhat.com,» [En línea]. Available: https://www.redhat.com/es/topics/containers/what-is-

docker.

[30] «Wireguard.com,» [En línea]. Available: https://www.wireguard.com/.


182

[31] «Keycloak.org,» [En línea]. Available: https://www.keycloak.org/.

[32] «Mariadb.com,» [En línea]. Available: https://mariadb.com/.

[33] «Alpinelinux.org,» [En línea]. Available: https://alpinelinux.org/.

[34] «Netdata.cloud,» [En línea]. Available: https://www.netdata.cloud/.

[35] «Wikipedia.org,» 7 Junio 2021. [En línea]. Available:

https://es.wikipedia.org/wiki/Secure_Shell.

[36] «Wikipedia,» 2020 Enero 13. [En línea]. Available:

https://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_aspectos.


183

7. Glosario

● Framework. Hace referencia al entorno de trabajo o marco de trabajo con una serie de

conceptos, prácticas y criterios estandarizados con el objetivo de enfocar de una mejor

manera una determinada problemática.

● Inversión de control. Se trata de un principio de diseño de software por el que, el flujo de

ejecución de un programa se invierte con respecto a un programa desarrollado con

metodologías tradicionales. Tradicionalmente, el desarrollador de un programa especifica

una serie de órdenes o acciones que se deben ejecutar por el programa, pero en un

programa con inversión de control, se especifican directamente las respuestas deseadas

para un suceso o solicitudes de datos concretos. De esta manera, el desarrollador deja toda

la responsabilidad a una entidad externa, obteniendo un mayor grado de abstracción.

● POJO. Hace referencia a clases de Java simples y que no son dependientes de ningún

framework. Un objeto de una clase POJO es una instancia que no extiende ni implementa

nada especial. Un ejemplo de esto puede ser una clase básica de Java que busque reflejar

por ejemplo las características de un animal o persona.

● SPI. Se trata de una API destinada a ser implementada o ampliada por una persona externa.

Por lo tanto, puede ser utilizada tanto para habilitar como reemplazar componentes y

extensiones de un framework.

Para el caso de Java, los SPIs son utilizados en las siguientes interfaces:

● Java Database Connectivity

● Java Cryptography Extension

● Java Naming and Directory Interface

● Java API for XML Processing

● Java Business Integration

● Java Sound

● Java Image I/O

● Java File Systems

● Número coprimo. Hace referencia a dos números primos entre sí, es decir, dos números

enteros a y b que tienen como máximo común divisor (MCD) al número 1.


184

● Registradas. Conjunto de declaraciones predefinidas que no es de uso obligatorio, aunque

sí muy recomendable. Ejemplos: iss (issuer), exp (expiration time), sub (subject) o aud

(audience).

● Públicas. Pueden ser definidos por el propio desarrollador, aunque para evitar colisiones

con otros proyectos se deben registrar en el registro de IANA.

● Privadas. Son declaraciones personalizadas que pueden ser utilizadas para compartir

información entre las partes que acuerden su utilización.

● URL. Uniform Resource Locator. Traducción al castellano: Localizador de Recursos

Uniforme.

● XRI. eXtensible Resource Identifier. Se trata de un nuevo sistema de identificación

diseñado específicamente para ser utilizado en Internet. En particular, se encuentra

enfocado al uso de identidades digitales bajo dominios cruzados. Los XRIs se presentan de

dos maneras: números y nombres. Habitualmente estos datos se encuentran registrados

para poder ser utilizados de manera equivalente los unos por los otros.

● Clúster dinámico. Se trata de un conjunto de servidores que hacen uso de gestores de

carga de trabajo. De esta manera, se pueden equilibrar las cargas del sistema, permitiendo

reducir y aumentar de manera dinámica los recursos del cluster. Es decir, en momentos

puntuales de alta carga el clúster podría crecer para soportar el aumento de la demanda,

mientras que, en momentos de baja carga se puede reducir los recursos disponibles. Esto

permite hacer una mejor optimización del hardware, ya que, en entornos cloud existen

multitud de sistemas que comparten continuamente los mismos recursos físicos.

● Controlador. Método o función del código fuente que se encarga de manejar y gestionar la

lógica de negocio que se debe aplicar, en función de la petición HTTP que un cliente

realiza sobre el sistema.

https://www.iana.org/assignments/jwt/jwt.xhtml

sistema para el - rua.ua.es

Documents