Monitorización en tiempo real de la conectividad de un nodo móvil

Equation Chapter 1 Section 1 Trabajo fin de grado Grado en Ingeniería de las Tecnologías de Telecomunicación Monitorización en tiempo real de la conectividad de un nodo móvil Depto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Autor: Juan García Fierro Tutor: Juan Antonio Ternero Muñiz Sevilla, 2020 2 3 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Monitorización en tiempo real de la conectividad de un nodo móvil Autor: Juan García Fierro Tutor: Juan Antonio Ternero Muñiz Profesor Colaborador Depto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2020 4 5 Trabajo Fin de Grado: Monitorización en tiempo real de la conectividad de un nodo móvil Autor: Juan García Fierro Tutor: Juan Antonio Ternero Muñiz El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2020 El Secretario del Tribunal 6 7 A mi familia A mis maestros 8 9 Agradecimientos Ahora, en la recta final de esta etapa de mi vida, es cuando más pienso en los que han estado a mi lado. Porque sin darme cuenta, han pasado cuatro años, seguramente los más intensos de todo lo que llevo de vida. Sin duda, rodeado de nuevas amistades, manteniendo antiguas, también, ha sido la etapa donde más a gusto me he sentido conmigo y con los que me rodean. No pararé de agradecer a todos mis amigos por su apoyo y cariño. A los que conocí antes de empezar este recorrido, por apoyarme aún no entendiendo qué estaba pasando en mi vida, sin entender por qué el Juan que ellos conocían estaba “mutando” a un nuevo Juan. Gracias, de nuevo, por haber seguido a mi lado aunque no haya podido dedicaros todo el tiempo que os merecéis. A las nuevas amistades que se han forjado durante estos cuatro años, quiero agradeceros que hayáis sido mi gran apoyo, mi día a día, con los que he compartido tantos momentos, que nunca podré olvidar. Porque de ser compañeros de clase, habéis llegado a ser los mejores amigos que se pueden tener. A mi pareja, porque desde que llegó a mi vida, todo ha ido a mejor. Porque ni yo mismo sabía de qué era capaz. Gracias a ella, que me ha acompañado durante todo este recorrido, he disfrutado del mismo como si cada día fuese el primero, viendo cómo las cosas cotidianas se convierten, con cariño, en maravillas. Gracias por apoyar mis decisiones y por haberme descubierto una nueva parte de mí mismo. A mis profesores, por todo el esfuerzo que han puesto durante estos años, no solo en sus asignaturas sino también en la dedicación personal por hacernos mejores personas. Gracias a toda mi familia, y a mis padres, por su apoyo en los momentos más difíciles durante las épocas de exámenes, por aguantarme en mis días malos y por haber estado ahí, intentando ayudarme en las asignaturas (aunque dejasen de estudiar ciencias antes de entrar a la Universidad). Y gracias a mi hermana, porque aunque ella no lo sepa, molestarme mientras estoy en mi cuarto escribiendo esta memoria en la crisis que estamos viviendo, me aleja de malos pensamientos y me ayuda a darme cuenta de que estoy rodeado de los mejores. Gracias de nuevo, a todos, por hacerme tan afortunado. Juan García Fierro Sevilla, 2020 16 Estado inicial de la base de datos 85 Anexo F: Instalación y configuración de la aplicación Android 86 Instalación de Android Studio 86 Instalación de la aplicación en el dispositivo móvil 86 Anexo G: Orden de despliegue de las herramientas 87 Apertura de puertos para acceso a los servicios 87 Arranque de Orion mediante Docker 88 Arranque del Servicio Web mediante STS 88 Envío de información desde el dispositivo móvil 89 Referencias 90 17 ÍNDICE DE FIGURAS Figura 1. Punto de "handover" (teórico). 21 Figura 2. Estructura de la solución. 25 Figura 3. Arquitectura física de la solución 25 Figura 4. Componentes del sistema y comunicación entre los mismos 29 Figura 5. Detalle de la entidad WifiInfo. 30 Figura 6. Detalle de la entidad SignalStrength. 31 Figura 7. Detalle de la entidad CellChangeInfo. 32 Figura 8. Diagrama de intercambio de mensajes - petición de token a Keyrock 35 Figura 9. Diagrama de intercambio de mensajes - publicación de contenido en Orion 35 Figura 10. Diagrama de intercambio de mensajes - suscripción a Orion 36 Figura 11. AppMonitorizacion – Menú principal. 37 Figura 12. AppMonitorizacion – Configuración del servidor. 38 Figura 13. AppMonitorizacion – Servicios disponibles. 38 Figura 14. AppMonitorizacion – Información de la aplicación. 39 Figura 15. Detalle del método getHeaders(). 40 Figura 16. Detalle del método getParams(). 41 Figura 17. Petición HTTP POST con credenciales correctos. 41 Figura 18. Respuesta HTTP a credenciales correctos. 41 Figura 19. Petición HTTP POST con credenciales incorrectos. 42 Figura 20. Respuesta HTTP a credenciales incorrectos. 42 Figura 21. Asociación del listener al controlador de telefonía. 43 Figura 22. Detalle de la clase SignalStrengthAndTime. 43 Figura 23. Constructor de la clase WifiInfoJSON. 44 Figura 24. Constructor de la clase SignalStrengthJSON. 44 Figura 25. Constructor de la clase CellChangeInfoJSON. 45 Figura 26. Detalle del método getHeaders(). 45 Figura 27. Aplicación Web – Menú principal. 47 Figura 28. Aplicación Web – Gestión de suscripciones. 48 Figura 29. Detalle del método getAuthToken(). 49 Figura 30. Clase SubscriptionJSON. 50 Figura 31. Autenticación de Orion en la Aplicación Web. 51 Figura 32. Detalle del método generateToken(). 51 Figura 33. Cancelación de suscripción en Orion. 52 18 Figura 34. Componentes de clases JSON. 53 Figura 35. Procesamiento de notificaciones en la aplicación 54 Figura 36. Diagrama de intercambio de mensajes - suscripción y autenticación en la aplicación web 55 Figura 37. Detalle de la clase SignalStrengthNotification. 55 Figura 38. Detalle de la clase SignalStrengthDb. 56 Figura 39. Gestión de notificaciones recibidas por Orion. 57 Figura 40. Aplicación Web – Selección de fechas. 58 Figura 41. Detalle del método getSeconds(). 58 Figura 42. Consulta a la base de datos. 59 Figura 43. Modelado de la información en la clase ChartData. 59 Figura 44. Recepción de la información en el código Javascript. 60 Figura 45. ChartJS – Asignación de datos a la gráfica. 60 Figura 46. ChartJS – Opciones de la gráfica. 61 Figura 47. ChartJS – Generación de la gráfica. 61 Figura 48. Aplicación Web – Error: Sin datos para fecha solicitada. 62 Figura 49. Aplicación Web – Error: Fechas incorrectas. 62 Figura 50. Aplicación Web – Gráfica de la potencia de la señal de la red móvil. 64 Figura 51. Aplicación Web – Tabla de cambios de estación base en la red móvil. 65 Figura 52. Niveles de potencia de señal de la red móvil. 65 Figura 53. Aplicación Web – Estadísticas de estaciones base en la red móvil. 66 Figura 54. Aplicación Web – Gráfica de la potencia de la señal de la red WiFi. 66 Figura 55. Aplicación Web – Tabla de cambios de red WiFi. 67 Figura 56. Niveles de potencia de señal de la red WiFi. 67 Figura 58. Descarga de Spring Tools 4. 73 Figura 59. Estructura de la carpeta myDockerCompose. 78 Figura 60. Fichero services – orden orion. 79 Figura 61. Fichero services – función stoppingContainers(). 79 Figura 62. Fichero services – función startContainers(). 79 Figura 63. Fichero services – función loadData(). 79 Figura 64. Fichero orion.yml – orion. 80 Figura 65. Fichero orion.yml – keyrock. 81 Figura 66. Fichero orion.yml – orion-proxy. 82 Figura 67. Fichero orion.yml – mongo-db. 83 Figura 68. Fichero orion.yml – mysql-db. 83 Figura 69. Contenedores dentro de la máquina virtual 84 Figura 70. Conexión entre contenedores 84 Figura 71. MySQL – tabla user. 85 Figura 72. MySQL – tabla oauth_client. 85 19 Figura 73. MySQL – tabla iot. 85 Figura 74. Descarga de Android Studio. 86 Figura 75. Conexión de dispositivo físico a Android Studio. 86 Figura 76. Reenvío de puertos. 87 Figura 77. Despliegue de Orion con todas sus dependencias 88 Figura 78. Asignación de dirección IP de Orion a la Aplicación Web. 88 Figura 79. Inicialización de la Aplicación Web. 89 Figura 80. Arranque de la Aplicación Web. 89 20 Notación ETSI Escuela Técnica Superior de Ingeniería SSID Service Set Identifier (identificador de una red inalámbrica) BSSID Basic Service Set Identifier (identificador físico de punto de acceso en una red inalámbrica) AP Access Point (Punto de Acceso Inalámbrico) C Lenguaje de programación C BS Base Station (Estación Base de telefonía) STS Spring Tool Suite 4 HTTP HyperText Transfer Protocol (Protocolo de Transferencia de Hipertexto) PDP PEP Policy Decision Point Policy Execution Point IoT Internet of Things (Internet de las Cosas) API Application Programming Interface (Conjunto de funciones y procedimientos que ofrece una biblioteca software) REST Representational State Transfer (Interfaz de comunicación que se basa en HTTP para transferencia de información) 21 1 INTRODUCCIÓN 1.1 Contexto El traspaso en telefonía móvil es el proceso por el cuál un dispositivo móvil se desplaza de una celda a otra por lo que cambia la estación base (BS) con la que está transmitiendo, siendo este proceso invisible para el usuario (sin afectar a la calidad de la llamada, si existiese, o sin aumentar la pérdida de paquetes, en envío de datos). De forma teórica, tal como estudiamos en la asignatura Estructura y Protocolos de Redes Públicas, las celdas de telefonía cubren un área hexagonal. Así, se forma una red de celdas donde cada una de ellas tiene su propia estación base, cubriendo áreas más grandes que lo que haría una celda de forma individual. Como se ha comentado anteriormente, cuando un dispositivo se aleja de la estación base de una celda y se va acercando a otra, parámetros como la calidad de la señal, la potencia de la señal, el porcentaje de errores en el canal… irán empeorando. Es entonces cuando, si el dispositivo detecta posibilidad de mejorar la señal, ocurre este suceso. Figura 1. Punto de "handover" (teórico). Igualmente, también se aplica a las redes WiFi: si para una misma red (con mismo SSID), se dispone de más de un Punto de Acceso Inalámbrico (AP), el dispositivo puede dotarse de un mecanismo que cambie entre los distintos AP disponibles sin afectar a la calidad de la conexión, permitiendo así desplegar una misma red en una superficie demasiado amplia como para cubrirla con un solo AP, y permitiendo igualmente al usuario desplazarse por todo el área sin perder calidad de transmisión. Sin embargo, desde el punto de vista del usuario, todas estas tecnologías son inapreciables (objetivo principal de las mismas). Es por ello que se abre un campo muy extenso de conocimientos donde poder investigar y obtener información acerca de estos sucesos gracias a los datos que nos ofrecen nuestros dispositivos. De forma paralela, la ciberseguridad también es un tema muy de moda actualmente. Diariamente somos informados de nuevas maneras de atacar los sistemas informáticos, de robos de información masivos… Cada vez más, las empresas demandan expertos en la materia para prevenir a sus empresas de estos ataques. Con el auge del IoT, se despliegan diariamente miles de nuevos dispositivos que utilizan Internet para comunicar datos a través de la red. Esta información puede ser de carácter sensible y necesitar algún tipo de protección. Igualmente, en el caso de ser información que pueda ser pública, interesa proteger a los receptores de esta información para evitar que se publiquen datos falseados para afectar negativamente al servicio. Por este motivo, uno de los puntos a tartar en el proyecto serán temas relativos a la seguridad. De esta manera, se busca así hacer un primer acercamiento a este tema que está tan demandado en la actualidad. 22 1.2 Motivación 1.2.1 Motivación técnica En primera instancia, veo necesario presentar los motivos técnicos por los cuáles se ha desarrollado este proyecto. El interés recae en conseguir diseñar un sistema seguro de monitorización de diversos agentes IoT, que sea accesible a través de una aplicación web de forma segura. En primer lugar, uno de los principales motivos es el de poder obtener información en tiempo real del terminal de manera sencilla. El sistema operativo Android ofrece una gran cantidad de mecanismos para conseguir consultar parámetros del teléfono. Por ello, tenemos a nuestro alcance un amplio campo de investigación mediante el cuál obtener los datos necesarios y modelarlos según nuestros intereses. Por otra parte, poder almacenar esta información en una base de datos y generar estadísticas y análisis puede ser de gran utilidad. Como se va a exponer durante el resto de la memoria, se pueden detectar, gracias a la aplicación web, posibles puntos de mejora de la conectividad del terminal en los que se podría actuar. La seguridad de los datos es un aspecto básico que acompaña al proyecto durante todo su ciclo de vida. Mediante distintos mecanismos, como la autenticación del emisor, se evita que la comunicación desde el dispositivo móvil hasta la aplicación web – atravesando un sistema intermedio: el servidor de contexto – sea manipulada o falseada. 1.2.2 Motivación personal Durante todos estos años estudiando este grado, siempre nos hemos visto enfrentándonos a distintos problemas planteados por los profesores. Desde la resolución utilizando conocimientos teóricos, como las matemáticas, al planteamiento de un algoritmo que resuelva dicho problema, con su posterior programación. Sin embargo, como he subrayado, siempre son entornos controlados: aunque no se conoce la solución directa, siempre se tiene la información necesaria para conseguirlo o se pueden plantear las dudas al profesor – o a tus compañeros. Ahora, sin embargo, el escenario cambia: este trabajo supone enfrentarse a un problema desconocido, un problema donde los límites los marcas tú: en función de tu habilidad, de tu esfuerzo y de tu dedicación, puedes llegar más o menos lejos. Este trabajo, en especial, tiene mucho valor para mí: desde primer curso, he sentido especial atracción por la programación. Desde las nociones básicas estudiando C, adentrarme algo más en la materia con el estudio de Java…, y acabando por conquistarme con la asignatura de segundo año, Fundamentos de Aplicaciones y Servicios Telemáticos. Ahí me dí cuenta que, aunque no necesariamente como futuro profesional, pero por lo menos sí como hobbie, la programación era uno de los campos que más me llamaba la atención. El tener las herramientas necesarias para construir algo desde cero, y resolver los problemas mediante simplemente el razonamiento (aunque posiblemente también con la ayuda de Internet), es lo que me conquistó. Y así, me he visto volcado en el diseño de una aplicación Android, aprendiendo a desarrollar en un sistema operativo tan “de moda” que me logra acercar al mundo real. Además, el propósito de la aplicación es, como poco, intrigante: obtener información del dispositivo en tiempo real, estudiar y modelar esa información y gracias a ello obtener estadísticas útiles que puedan ayudar a tomar una decisión. Sin duda, explorar todas las posibilidades que ofrece Android acerca de datos relativos a la conectividad, y a tantos aspectos que llevamos tantos años estudiando, consigue hacerte ver que, pese a lo que se piense muchas veces, los conocimientos teóricos te acercan, poco a poco, a la realidad. Además, el estudio de la asignatura Seguridad el tercer año del grado, me llevó a plantearme la posibilidad de optar por esa rama una vez finalizados mis estudios. Con este trabajo pretendo, también, profundizar en los conocimientos aprendidos, de una manera más experimental, de manera que pueda ir conociendo los distintos aspectos de la ciberseguridad. 23 1.3 Objetivos Con la realización de este trabajo, se pretende conseguir obtener información en tiempo real sobre la conectividad de un dispositivo móvil. Adicionalmente, se busca almacenar esta información de manera persistente para generar gráficas y estadísticas que muestren al usuario un registro de la calidad de las conexiones monitorizadas. El objetivo principal es estudiar el fenómeno del handover o traspaso. Este suceso ocurre tanto en la red de telefonía móvil, como en la red WiFi, por lo que se estudiará en ambos escenarios de la major forma possible. Es por ello que se pretende detectar el momento en el que ocurre dicho traspaso, así como conocer información relativa a la señal (como, por ejemplo, la potencia de la misma), para así poder tomar, más adelante, decisiones en función de las gráficas que se aportarán. Como se ha comentado anteriormente, el objetivo es monitorizar el dispositivo para comprobar si, efectivamente, ocurre el traspaso y detectar cuándo y por qué sucede. De forma paralela, se quiere conseguir desacoplar el envío de información desde el dispositivo, de la recepción de la misma en el servidor, con el fin de dividir el problema en bloques y facilitar la implementación. Este desacoplo se hará mediante el uso de tecnologías de IoT, como son las herramientas que aporta FIWARE. Estas herramientas permiten que cualquier dispositivo que envíe información siguiendo sus estándares, pueda comunicarse con otras aplicaciones de forma sencilla. En nuestro caso, será el dipositivo móvil el que a través de una API REST publique información, aunque el problema puede ser extendido a cualquier dispositivo con posibilidad de comunicación externa. Por ultimo, se pretende dotar a las herramientas de FIWARE de seguridad, implementando distintos mecanismos que permitan asegurar la aplicación de agentes externos. En concreto, se utilizarán herramientas que permitan la autenticación frente a los servicios ofrecidos, de modo que usuarios no registrados no puedan acceder a determinados recursos protegidos. 24 2 DISEÑO Y ESTRUCTURA DE LA SOLUCIÓN En esta sección va a describirse de manera esquemática la solución a implementar. De esta manera, se pretende dar una visión general de la estructura de la misma, que se irá desarrollando a lo largo del documento de manera más técnica, concretando detalles de código y de implementación relevantes. Para el diseño, se ha optado por la división del problema en bloques, independizando así las tareas a realizar y convirtiendo un problema complejo en varios problemas simples. De este modo, la solución puede dividirse en tres bloques principales: obtención y envío de información desde el dispositivo móvil, control de la información, y recogida y almacenamiento de la misma. Para el primer bloque, encargado de enviar datos acerca del suceso estudiado, se va a diseñar una aplicación en Android (con lenguaje de programación orientada a objetos, Java). Para el manejo de información de contexto, y como servidor intermedio entre el emisor y el receptor final de los datos, se van a utilizar tecnologías de FIWARE, concretamente Orion Context Broker [1]. Se explicarán más adelante las herramientas utilizadas para ofrecer seguridad a la comunicación desde y hacia Orion. Finalmente, utilizando Spring Tool Suite [2], se busca desarrollar una aplicación web que reciba información desde Orion y la modele y almacene de forma persistente, generando gráficas informativas para estudiar el “handover” o traspaso. Con estos tres bloques en funcionamiento, el usuario podrá monitorizar la conectividad del dispositivo habilitando las opciones de la aplicación Android y configurando la aplicación web de la misma manera. Además, gracias a las herramientas de seguridad, podrá estar seguro de que la información visualizada no ha sido manipulada por agentes externos ya que la aplicación web también tendrá su propio mecanismo de autenticación. Por último, destacar que la solución por la que se ha optado es escalable. Permitiría, en caso de ser necesario, instalar la aplicación en más dispositivos móviles y configurar la aplicación web desarrollada para que solicite información de todos los terminales. De esta forma, se podría controlar, por ejemplo, la conectividad de una flota de dispositivos cuyo sistema operativo fuese Android de una forma sencilla. De modo esquemático, la solución dividida en tres bloques se muestra en la figura a continuación. 25 Figura 2. Estructura de la solución. Además, para poder entender el escenario y la configuración utilizada, a continuación se muestra un esquema de la arquitectura física de la solución, donde se pueden observar los distintos componentes utilizados. A lo largo de toda la memoria se irán comentando cada uno de ellos. Figura 3. Arquitectura física de la solución 32 Figura 7. Detalle de la entidad CellChangeInfo. Los atributos de la entidad son los siguientes: - id: identificador de la entidad. Debe ser único para un mismo tipo. - type: identificador del tipo de la entidad, que indica qué representa. - ci: identificador de la estación base en una celda - dataDate: fecha en la que se ha registrado el dato. - pci: identificador físico de la estación base en una celda - period: cantidad de tiempo, en milisegundos, que ha permanecido la señal en este estado Como se puede observar, en la entidad se incluye información sobre el periodo de tiempo que el dispositivo ha estado conectado a dicha estación base. Para ello, es necesario dotar de memoria a la aplicación Android, ya que no se podrá enviar esta información hasta que haya habido un cambio de celda. Esto implica, por lo tanto, que la información sobre una estación base concreta no se enviará al servidor hasta que el dispositivo haya realizado el traspaso, momento en el que Orion recibirá la información y se la notificará al servidor web en caso de estar suscrito. 3.3 Suscripciones al contenido Las suscripciones en Orion son un apartado muy importante para el desarrollo de aplicaciones de IoT. De manera resumida, están enfocadas en notificar al suscriptor de un cambio en alguna entidad. Como ya hemos visto anteriormente, se van a utilizar tres entidades distintas para el intercambio de información de contexto. De manera periódica, el dispositivo móvil enviará información acerca de estas tres entidades. Por ejemplo, cuando varíe la potencia de la señal móvil, cuando empiece a transmitir con una estación base distinta a la anterior… Cuando se envía esta información a Orion, se produce un cambio en los atributos de dicha entidad. El mecanismo de suscripciones permite a agentes externos solicitar al servidor que envíe una notificación, que se puede personalizar, con cierta información sobre dicha entidad. Los aspectos a personalizar sobre las notificaciones, son, entre otros, los siguientes: - La entidad de la que quiere recibir notificaciones. - Las condiciones para que se envíe una notificación: cambio en ciertos atributos, cambio en cualquier 33 atributo, rango de cambio… - El número máximo de notificaciones en un periodo de tiempo concreto. Eso es útil si no queremos sobrecargar el servidor o al propio agente que se suscribe. - La URL de destino donde se debe enviar la notificación. - Es posible solicitar que en la notificación se incluya la información de la entidad completa o solo ciertos atributos de la misma. - Se permite añadir pares clave – valor a la URL destino, mecanismo mediante el cuál implementaremos autenticación en la aplicación web desarrollada. Este apartado se comentará más adelante. Para realizar una suscripción, hay que enviar una petición POST a Orion a /v2/subscriptions, con toda la configuración elegida que se ha comentado anteriormente. Una vez establecida la suscripción, Orion enviará en el mensaje de respuesta, en caso de que se haya tramitado correctamente, un identificador de dicha suscripción que permitirá al agente externo cancelarla enviando una petición DELETE incluyendo el identificador. De la misma manera, accediento a /v2/subscriptions se pueden consultar todas las suscripciones activas en el momento, así como el último momento en el que se envió una notificación. 3.4 Seguridad de Orion – Wilma y Keyrock Un punto importante que se quería tratar en este proyecto era la seguridad. En concreto, se han desarrollado distintos mecanismos para dotar a los distintos componentes de la misma. Un ejemplo de esto es la aplicación web desarrollada, que, como se explicará en el capítulo correspondiente, se ha dotado de un mecanismo de autenticación de tipo clave – valor mediante el cuál Orion recibe un token de acceso generado en la aplicación que envía en la URL de notificación. Así, se puede comprobar con cada una de las notificaciones recibidas si el emisor es Orion (porque la clave coincide con la que se envió previamente) o por el contrario es un agente externo que envía información maliciosa. De la misma manera, el servidor de contexto Orion ha sido asegurado mediante herramientas disponibles a través de FIWARE para permitir solo el acceso a usuarios identificados y con permisos para ello. Primero, se hará una explicación teórica de los aspectos relativos a la seguridad que se van a utilizer en el proyecto. Posteriormente, y a través de los siguientes capítulos de la memoria, se irán abordando los distintos mecanismos utilizados para ver cómo se han implementado. 3.4.1 Definiciones En primer lugar, antes de analizar las herramientas, son necesarias algunas aclaraciones sobre qué vamos a utilizar. En este caso, vamos a utilizar el nivel más básico de seguridad: la autenticación. A través de las herramientas disponibles, vamos a realizar la comprobación de que el usuario que solicita acceso a Orion es un usuario registrado en la aplicación. Keyrock es el componente responsable de la gestión de identificación. Actúa como PDP: recibiendo unas credenciales, comprobará si son correctas o incorrectas y lo comunicará a la entidad que haya realizado la consulta. Por otro lado, Wilma es el PEP Proxy: situado frente al servicio que se quiere proteger (Orion), recibe peticiones desde el exterior y a través de las credenciales recibidas, consulta al PDP para comprobar si son correctas o no. Una vez obtenida la respuesta, comunica el resultado al emisor externo, permitiendo o no el acceso al recurso solicitado. 34 Orion Context Broker es un servidor de contexto, que implementa la API RESTFUL NGSI V2 [8]. Esta API define el modelo de datos necesario para la información y una interfaz para el intercambio de la información. La interacción con la API se puede realizar mediante un cliente REST, que envíe peticiones HTTP con envío o consulta de información. De manera general, se utiliza el método GET para la petición de información, el método POST para el envío completo de una nueva entidad que no estuviese previamente creada en el servidor y el método PATCH para actualizar campos de una entidad existente en el servidor. Además, permite la suscripción a las entidades para notificaciones en función de los cambios ocurridos en el servidor. 3.4.1.1 Wilma Wilma actúa como PEP Proxy para Orion. Se combina con Keyrock para establecer un control de acceso a Orion, asegurando así el servidor de usuarios externos. Recibe peticiones del exterior y mediante consultas a Keyrock permitirá al usuario acceder a Orion o bien denegará la petición. 3.4.1.2 Keyrock Keyrock es el componente de FIWARE que actúa como Identity Management. Keyrock almacenará los usuarios, aplicaciones y sensores registrados, y concede los derechos de acceso para el acceso a los recursos en función de la información obtenida desde Wilma. Así, Wilma recibe las peticiones desde el exterior, consulta a Keyrock, que se encarga de comprobar los permisos, y éste comunica a Wilma la decisión para que proceda a permitir o denegar el acceso. 3.4.2 Esquema de actuación Para comprender mejor el funcionamiento conjunto de Wilma y Keyrock, es más sencillo comprobar un ejemplo. Este sería el orden de actuación: 1. Un sensor, dado de alta en la aplicación, solicita a Keyrock un token de acceso a través de su usuario y contraseña ya registrados en la aplicación. 2. Keyrock comprueba si es correcto. En caso afirmativo, genera un token y lo envía al solicitante, manteniéndolo válido durante un periodo determinado (de forma predeterminada, una hora). 3. El sensor quiere publicar información en Orion. Envía la petición HTTP PATCH a Wilma, incluyendo en la cabecera el token de acceso recibido previamente. 4. Wilma, al recibir la petición, envía a Keyrock el token recibido. 5. Keyrock comprueba si pertenece a algún sensor activo y en caso de ser correcto, envía la respuesta a Wilma junto con información del sensor. 6. Wilma recibe la respuesta de Keyrock, y en caso de ser afirmativa, permite la publicación en Orion de la información recibida del sensor. En caso de que en alguno de estos pasos se haya comprobado que el usuario no está registrado o que el token de acceso aportado es inválido, se le comunicará al emisor y se le denegará el acceso. Además, a modo de esquema, se presenta la comunicación que se establece entre los “sensores” y Keyrock para la obtención de un token de acceso, aunque en los capítulos correspondientes viene en detalle a través de capturas mediante Wireshark o diagramas. 35 Figura 8. Diagrama de intercambio de mensajes - petición de token a Keyrock Figura 9. Diagrama de intercambio de mensajes - publicación de contenido en Orion 36 Figura 10. Diagrama de intercambio de mensajes - suscripción a Orion 3.4.3 Estructura de la aplicación Para realizar la protección mediante autenticación de Orion, se ha dado de alta una aplicación en Keyrock donde se han situado los distintos elementos necesarios. Entre ellos, junto con el usuario con acceso a la información (definido en el archivo YAML [42] explicado en el Anexo E), cabe destacar que se han dado de alta dos sensores en la aplicación: - El primero de ellos, destinado a la autenticación de la aplicación Android desarrollada, para permitir que pueda publicar información en Orion acerca de los parámetros a monitorizar. - El segundo de ellos, destinado a la autenticación de la aplicación web desarrollada, que permite obtener un token de acceso para realizar las suscripciones a las entidades de Orion. 37 4 ENVÍO DE INFORMACIÓN: APP ANDROID El propósito de esta aplicación desarrollada en Android es el de recopilación, manipulación y envío de información acerca de la conectividad del dispositivo donde esté instalado, en este caso en el Xiaomi Redmi Note 7. De forma general, la aplicación, una vez otorgados los permisos necesarios por el usuario, accede a información relativa a la conectividad a través de clases definidas para ello. Así, obteniendo datos sobre la potencia de la señal (tanto WiFi como de telefonía), estación base a la que se encuentra enviando información, punto de acceso inalámbrico (AP) mediante el cuál obtiene acceso a Internet…, será posible monitorizar el traspaso (Handover en inglés) para un posterior estudio. El servidor encargado de recibir esta información es el Orion Context Broker, asegurado mediante Wilma y Keyrock, como ya se ha comentado. El usuario de la aplicación podrá decidir en cada momento cuáles son los parámetros que quiere que se envíen en cada momento, a través de dos selectores del menú, haciendo así posible una distinción entre el traspaso de la interfaz WiFi o de la interfaz de telefonía móvil. 4.1 Layout de la aplicación A continuación, se muestra de forma breve el diseño de la interfaz de la aplicación con el fin de explicar su utilidad. Figura 11. AppMonitorizacion – Menú principal. Este menú, al que se accede directamente al arrancar la aplicación, nos permite decidir entre acceder a la configuración del servidor al que se envían los datos, activar la recogida y envío de información o bien consultar los datos de la aplicación. Cuando pulsamos sobre el “Configuración del servidor”, nos aparecerá esta simple ventana: 38 Figura 12. AppMonitorizacion – Configuración del servidor. Por defecto, se muestra la dirección IP del equipo en el que está escuchando el PEP Proxy Wilma y el PDP Keyrock para el envío de datos de la aplicación. En este escenario planteado, tanto Wilma como Keyrock deben estar situados en el mismo equipo. En el caso de que la dirección IP cambiase o que se quisiese enviar a otro equipo por cualquier motivo, se debe ingresar la nueva IP y pulsar sobre el botón “Guardar”. Una vez hecho esto, todas las peticiones HTTP enviadas por la aplicación serían a esta nueva dirección IP. En el menú principal también se encuentra el acceso a “Servicios disponibles”: Figura 13. AppMonitorizacion – Servicios disponibles. 39 En esta actividad, el usuario puede decidir qué información quiere que sea enviada al servidor. Por defecto, los dos selectores estarán desactivados. Cuando uno de ellos se activa, comienza a recoger información y a enviarla de forma periódica al servidor configurado en la actividad anterior. En el caso de activar alguno (o ambos) y regresar al menú principal, el programa recordará las selecciones realizadas para dar la posibilidad de desactivarlas accediendo de nuevo a esta actividad. Por último, se cuenta con un último icono, “Saber más”, que dirige a la página de información relativa a la aplicación. Figura 14. AppMonitorizacion – Información de la aplicación. Esta pantalla es simplemente para ofrecer al usuario información acerca de: autor, fecha y una descripción general de su funcionalidad. 4.2 Clase Application.java En el funcionamiento de la aplicación, hay una clase con especial relevancia que merece ser explicada de forma independiente: la clase de tipo Application. En concreto, existe en la aplicación una sola clase que hereda de Application, AppMonitorizacionApplication. La característica principal de esta clase es que por defecto, se crea una instancia de la misma con el arranque de la aplicación, y permanece así durante todo el ciclo de vida de la aplicación. En este caso, se utilizará para los siguientes propósitos: - Permitir la transferencia de objetos entre distintas actividades de la aplicación, evitando mecanismos complejos de envío de objetos. - Manejar y mantener referencias a instancias de clases que implementan el patrón Singleton. - Declarar variables globales para su uso y acceso durante toda la aplicación (como, por ejemplo, la dirección IP del servidor). 40 - Realizar la tarea periódica de autenticación en el servidor, enviando las credenciales (nombre del sensor dado de alta en la aplicación, y contraseña) y obteniendo el token de acceso 1 necesario. 4.3 Autenticación en Orion Como se ha comentado en el punto anterior, el envío de información a Orion está protegido por un token de acceso. Así, cualquier sensor IoT o dispositivo que intente publicar datos de forma no autorizada, será rechazado por el servidor. El acceso se hará mediante Wilma, el PEP Proxy configurado para solo permitir envío de información cuya petición HTTP lleve en la cabecera un token de acceso adecuado. Para obtener este token, desde la aplicación Android es necesario solicitarlo a un gestor de identificación de FIWARE, Keyrock. Para ello, se utiliza la API Volley explicada más adelante. En particular, cabe destacar los dos métodos utilizados para añadir a la petición HTTP la cabecera “Authorization”, donde indicamos a qué aplicación queremos obtener acceso, y para añadir en el cuerpo del mensaje las credenciales. Es importante comentar esta cabecera junto con su contenido, ya que Orion espera una información determinada para tomar la petición como válida. De manera resumida, esta cabecera contiene las credenciales necesarias para autenticarse, como usuario, en un servidor. Aunque hay muchos tipos distintos de autenticación, la más utilizada es, como en este caso, la petición de tipo “Basic”. En este tipo, las credenciales se aportan en el mensaje concatenando el usuario y la contraseña separados por dos puntos, de la forma “usuario:contraseña”, y finalmente codificando la cadena resultante en base64. En este caso, Keyrock espera que en la cabecera “Authorization”, el contenido sea el usuario y contraseña definidos para la aplicación a proteger. Como se puede observar en el Anexo C, en la base de datos existe una tabla de nombre oauth_client. En esta tabla, para cada una de las aplicaciones definidas se establece un identificador junto con un “secreto de la aplicación”, es decir, una contraseña. En este caso, se cuenta simplemente con una aplicación declarada en Keyrock. Los datos de la misma se pueden ver en el archivo myDockerCompose/mysql-data/backup.sql, en la tabla de la base de datos mencionada anteriormente. La aplicación tiene de identificador “iot-application-mobile-monitoring” y de contraseña “iot-application-mobile-secret”. Siguiendo los pasos explicados, la codificación en base64 sería la siguiente: aW90LWFwcGxpY2F0aW9uLW1vYmlsZS1tb25pdG9yaW5nOmlvdC1hcHBsaWNhdGlvbi1tb2JpbGUtc2VjcmV0 Como podemos ver, coincide con la cabecera de la imagen inferior. Si estas credenciales no fuesen correctas, la respuesta del servidor sería “401 Unauthorized”. De esta manera, evitará que un usuario externo pueda obtener un token sin conocer los datos de acceso a la aplicación. Figura 15. Detalle del método getHeaders(). 1 De ahora en adelante, se utilizará token o token de acceso para definir la cadena enviada por Keyrock con la cuál un usuario puede autenticarse en los servicios ofrecidos, una vez ha aportado las credenciales correctamente. 41 Figura 16. Detalle del método getParams(). A continuación, se muestra el mensaje HTTP enviado y la respuesta recibida en caso de ser las credenciales correctas, y en el caso de solicitar acceso de forma inválida. Estos mensajes corresponden con la comunicación entre la aplicación Android y el PDP Keyrock, con el fin de obtener el token de acceso requerido. Figura 17. Petición HTTP POST con credenciales correctos. Figura 18. Respuesta HTTP a credenciales correctos. 48 Pulsando en el enlace de la parte inferior de la pantalla, podemos acceder al menú de gestión de las suscripciones a Orion. Es aquí donde se podrán consultar las que están activas en cada momento y se podrán activar o desactivar en función de qué información queramos almacenar en la base de datos. Figura 28. Aplicación Web – Gestión de suscripciones. Cuando alguna de las suscripciones se activa, el estado cambiará a “ON” haciendo saber al usuario que se está recibiendo información de Orion. En caso de volver a pulsar en el botón “Suscripción” habiendo una activa, esta acción no se llevará a cabo para evitar la duplicidad de información. Las suscripciones seguirán activas de manera indefinida hasta que el usuario decida cancelarlas, por lo que aunque volvamos al menú principal o cerremos el navegador, la próxima vez que ingresemos a esta página seguirá el mensaje “Estado de la suscripción: ON” en las suscripciones pertinentes. 5.2 Autenticación en Orion De forma similar a la aplicación Android que actúa como sensor IoT, el servicio web debe estar autenticado en Orion para poder realizar suscripciones al contenido. En este caso, no estamos protegiendo Orion para que un usuario no autorizado envíe información maliciosa al servidor. Por el contrario, dotamos a Orion de seguridad para que la información manejada solo pueda ser accedida por usuarios con permisos para ello. Así, evitamos que un tercero pueda obtener datos relativos a la conectividad del dispositivo monitorizado. Para realizar la autenticación, se ha creado una clase, ScheduledTasks, con la anotación @Scheduled en su método getAuthToken(), que se ejecuta de forma periódica cada 45 minutos. A su vez, para habilitar la ejecución de tareas periódicas, es necesario que en la clase Application se añada la anotación @EnableScheduling [22]. 49 Figura 29. Detalle del método getAuthToken(). Se establece como URL destino la dirección IP de la máquina donde está situado Keyrock, y el puerto 3005 TCP. En este caso, es Keyrock quien se encarga de generar el token. Al igual que en la aplicación Android, se ha añadido la cabecera “Authorization”. La finalidad de la misma se ha explicado previamente en el apartado 4.3: Autenticación en Orion. Una vez enviada la petición POST, se procesa la respuesta y se almacena el token de acceso obtenido en el contexto de la aplicación, para poder acceder a él desde cualquier parte de la misma. Como por defecto tiene una caducidad de una hora, por seguridad, este es el motivo por el cuál se hace de esta una tarea periódica. 5.3 Suscripción a Orion y securización de notificaciones La suscripción a Orion tiene como finalidad la de recibir información relativa a las entidades que se indiquen en la misma. Así, una vez que el usuario pulse sobre uno de los botones de “Suscripción” (o “Desuscripción”, para lo contrario), se enviará una petición a una URL determinada que capturará el controlador MenuSubscriptionsController. Una vez capturada, se enviará una petición POST al puerto 1027 TCP, a la URL /v2/subscriptions, donde se le indica a Orion de qué entidad o entidades se quiere recibir notificaciones de cambios en sus valores. Como ya se ha comentado anteriormente, Orion está protegido frente a cualquier tipo de peticiones externas, obligando a los usuarios a acceder a través de Wilma (de ahí que la petición POST vaya dirigida al puerto 1027 TCP), por lo que a la cabecera del mensaje también habrá que añadirle la cabecera “X-Auth-Token” con el token que se le ha otorgado a la aplicación en la tarea periódica ya comentada. 5.3.1 Clase SubscriptionJSON.java Para la generación del cuerpo del mensaje de la suscripción, se ha creado una clase propia que oculte al controlador la sintaxis del objeto JSON a enviar. Se trata de la clase SubscriptionJSON, que recibe por parámetros todos los datos necesarios que necesita Orion conocer y los modela en forma de cadena JSON. 50 Figura 30. Clase SubscriptionJSON. De forma predeterminada, si no se indica lo contrario, el tiempo de expiración se ajusta a una fecha lejana, para simular una suscripción indefinida. Si se quisiese, se podría indicar como quinto parámetro del constructor (en caso contrario, indicarlo con null). A su vez, recibe el token generado en el servidor. Cabe destacar de la suscripción el campo “httpCustom”. Se ha utilizado para poder implementar un mecanismo de autenticación en el servidor, como se verá en el siguiente apartado. En una suscripción básica a Orion, uno de los campos a especificar es el atributo “http”, con el subcampo “url”, donde se le indica a Orion la URL a la que debe enviar las notificaciones de dicha suscripción. En nuestro caso, nuestra aplicación web está dotada de un mecanismo de autenticación, mediante el cuál se ignorarán todas las notificaciones recibidas que no lleven incluido un par clave – valor específico. La generación de esta clave se detalla en el próximo apartado. Cada vez que se vaya a enviar una notificación desde Orion a nuestra aplicación, es necesario que adjunte en la URL del mensaje el par clave – valor generado en el servidor para poder verificar quién es el emisor. La manera de indicar a Orion que debe incluir estas credenciales no puede ser modificando manualmente la URL de notificación, ya que nos avisaría de que tiene un formato inválido. Para poder realizar esto, Orion cuenta con una modificación en la suscripción: en vez de utilizar el atributo “http” como se ha comentado anteriormente, se debe reemplazar por “httpCustom”. Se añade pues, además del campo “url” a la suscripción, el campo “qs”. En este campo, se especifican uno a uno los pares clave – valor que debe utilizar Orion para las notificaciones. Por esto mismo, en este caso se le indica a Orion que debe enviar junto a la URL el atributo de nombre “token” junto con un valor generado en la aplicación web. Por defecto, se configura en el campo “condition” los atributos de la entidad que deben cambiar para lanzar la notificación. Al dejarlo vacío, como se observa en este caso, se indica a Orion que cualquier cambio debe generar una notificación. 51 Por último, el atributo “attrs” dentro de “notification”, indica los atributos que se tienen que enviar en cada una de las notificaciones. Al estar vacío, implica que se envíe la entidad completa en cada notificación. Figura 31. Autenticación de Orion en la Aplicación Web. 5.3.2 Generación de token aleatorio Para poder indicar a Orion que las notificaciones las envíe añadiendo a la URL el parámetro “token” junto con un token de autenticación, es necesario primero tener un mecanismo de creación del mismo implementado en el servidor. El procedimiento es el siguiente: cada vez que el usuario pulsa sobre uno de los tres botones que lanzan la suscripción, se genera un nuevo token aleatorio de 20 caracteres. Este se almacenará en la clase Application, para posteriores consultas cuando se manden notificaciones de cambios en el servidor Orion. La generación del mismo se ha realizado mediante la adaptación de un código encontrado en la web baeldung [23]. Será una cadena de caracteres alfabéticos en minúsculas, generados de forma aleatoria, con lo que la posibilidad de que se repita el mismo valor para el tiempo de vida de la aplicación es extremadamente baja. Figura 32. Detalle del método generateToken(). 52 5.3.3 Cancelación de suscripciones Por último, es imprescindible dotar al servicio de un mecanismo para realizar la desuscripción de las entidades de las cuáles no se requiera recibir más notificaciones. Orion está dotado de un mecanismo para ello, que se puede utilizar capturando correctamente el mensaje de confirmación de la suscripción previa. En la respuesta de Orion a la suscripción, se incluye el “subscriptionId”, identificador de la suscripción que se acaba de establecer. Este identificador se almacena en la clase Application para asegurar que no se pierde la referencia. Cuando el usuario solicita la desuscripción de la entidad, el procedimiento seguido es el envío de una petición DELETE [24] a la URL /v2/subscriptions/identificador, adjuntando nuevamente el token de acceso (para evitar que usuarios externos nos capturen un mensaje y utilicen el identificador para cancelar nuestra suscripción). Con este mecanismo tan simple, Orion recibe el identificador y busca de entre todas las suscripciones activas la que coincida. En el caso de coincidencia, elimina la suscripción y cesa el envío de notificaciones. Figura 33. Cancelación de suscripción en Orion. 5.4 Recepción y almacenamiento de información Una vez establecida alguna suscripción en el servidor, Orion comenzará a enviar notificaciones en el caso de que alguna entidad existente cambie alguno de sus atributos. Estas notificaciones, debido a cómo se han configurado las distintas suscripciones, siempre seguirán el mismo formato: constarán de un solo objeto representado en formato JSON, con todos los atributos de la entidad tal como están en el servidor en el momento de la notificación. En el capítulo dedicado a Orion se detallan las entidades desarrolladas junto con todos sus atributos, aunque en la siguiente figura se puede ver un esquema de las mismas. 53 Figura 34. Componentes de clases JSON. Esto ocurrirá cuando el dispositivo móvil, actuando como sensor IoT, envíe información acerca del traspaso con la aplicación diseñada. Orion cambiará los valores de los atributos de sus entidades cuando reciba esa información, y comprobará si hay alguna suscripción activa para dicha entidad. En caso afirmativo, generará una notificación adjuntando el token recibido por el servidor, junto con una copia de todos los atributos de la entidad que ha sufrido algún cambio, como ya se ha comentado previamente. En el siguiente esquema se muestran las distintas etapas por las que pasa la petición y posteriormente se entrará en detalle en cada una de ellas. 54 Figura 35. Procesamiento de notificaciones en la aplicación 5.4.1 Comprobación de autenticación en el servidor La primera decisión que se toma en los métodos de notificación (en la clase MenuSubscriptionsController) es la de aceptar o denegar la información recibida, en función de la autenticidad del emisor. Para ello, se obtiene el token recibido como parámetro la URL de la petición y se comparará con el almacenado en la aplicación web, que será el que previamente se generó y se envió en la suscripción. En el caso de que coincidan, se procede a modelar la información recibida para almacenarla en la base de datos. En caso contrario, simplemente se ignorará la petición, sin enviar ninguna información extra al emisor, ya que no se puede asegurar que sea Orion el mismo. A continuación se muestra un esquema que ilustra el procedimiento seguido por la aplicación. 55 Figura 36. Diagrama de intercambio de mensajes - suscripción y autenticación en la aplicación web 5.4.2 Recepción en clases JSON La recepción de la información tiene varias fases. En una primera instancia, se da por hecho que puede llegar más de una entidad en la misma notificación. Sin embargo, las suscripciones están personalizadas de manera que, como ya se ha comentado, solo se envíe un único objeto en formato JSON por notificación. Mediante la anotación @RequestBody [25], se mapea el cuerpo del mensaje a un objeto del tipo indicado (SignalStrengthNotification, WifiInfoNotification o CellChangeNotification). En estas clases se almacenan simplemente dos variables: una cadena de texto que representa el identificador de la suscripción por la cuál se ha enviado una notificación, y una lista de objetos de un tipo determinado en formato JSON. La estructura de las clases donde se almacenan los objetos JSON recibidos en la notificación debe ser una determinada, de forma que automáticamente se asignan los valores a los campos destinados. La estructura de estas clases es la mostrada en la figura anterior. Así, si se recibe una notificación de la entidad SignalStrength, se almacenará en un objeto de la clase SignalStrengthNotification una lista de objetos SignalStrength, cuyos atributos se corresponden con objetos simples que almacenan tipo definido en Orion y valor que ha tomado en dicha notificación. Figura 37. Detalle de la clase SignalStrengthNotification. 56 El acceso a los valores de cada uno de los atributos de la entidad es sencillo. Siguiendo el orden, recorremos la lista de objetos almacenados en las clases Notification, y una vez obtenida una referencia al objeto, utilizando los GETTERS [26], obtenemos el atributo, que está representado por un objeto de la clase con el mismo nombre. Una vez obtenido el objeto, existen dos métodos, getValue() y getType(). Con el primero, obtenemos en una cadena de texto el valor del atributo en la notificación, y con el segundo el tipo definido en la entidad. Aunque puede que no haya quedado el mecanismo totalmente claro, en el próximo apartado se incluye una figura donde se puede observar cómo se recorre la lista de objetos y cómo se accede a sus atributos como se ha descrito previamente. 5.4.3 Almacenamiento en clases Entity Ya se ha comentado la manera de extraer los valores de los atributos de una notificación. Sin embargo, para que posteriormente se pueda utilizar esta información para la generación de gráficas y estadísticas, es necesario dotar al servidor de almacenamiento persistente. Para ello, se utiliza MySQL, donde se ha creado una base de datos, “db_spring”, con tres tablas donde se almacenará la información recibida. Spring provee de una manera eficiente de almacenar información a través de clases Java. A través de la anotación @Entity [27], se informa a Hibernate que esta clase va a ser una tabla dentro de nuestra base de datos. Gracias a esta tecnología, el programador puede abstraerse de la gestión de la base de datos, ya que mediante esta anotación es posible almacenar objetos de una clase en tablas de bases de datos relacionales, permitiendo la búsqueda e inserción sencilla de elementos. Las tres clases que se han utilizado para ello tienen el mismo nombre que las que almacenan el contenido JSON de las notificaciones, sufijadas por “Db”. Así, SignalStrengthDb es la clase enfocada en el almacenamiento y gestión de la información recibida a través de la clase SignalStrength, y se creará una tabla de nombre signal_strength_db dentro de la base de datos. Figura 38. Detalle de la clase SignalStrengthDb. Para el gestión del almacenamiento, se utilizan clases que heredan de CrudRepository [28]. Esta clase provee de operaciones básicas para el manejo de tablas en la base de datos. Una de las características principales de CrudRepository es que permite definir métodos del tipo find…By… , de modo que se auto-generan y se pueden utilizar para realizar consultas a la base de datos. Utilizando el método save() de la clase hija de CrudRepository correspondiente, se indica que se debe almacenar el objeto especificado por parámetros en la base de datos. Así, nos permite abstraernos del acceso a la base de datos de la manera convencional, mediante órdenes propias del lenguaje, y facilita la comunicación con la base de datos permitiéndonos almacenar objetos complejos de forma sencilla. 57 Figura 39. Gestión de notificaciones recibidas por Orion. Cabe destacar que todas las fechas almacenadas en la base de datos siguen el convenio de estar representadas mediante la cantidad de segundos desde dicha fecha al 1 de enero de 1970. Esto será importante de cara a la consulta a la base de datos en función de la fecha registrada. 5.5 Patrón MVC para generación de gráficas Para la correcta gestión de la generación de gráficas y estadísticas acerca del traspaso estudiado, se sigue el patrón modelo – vista – controlador para dividir las tareas a realizar. Para cada una de las gráficas, se cuenta con la vista (fichero .jsp que presenta la información), junto con el controlador (clase Java con la anotación @Controller [29]) y el modelo, una clase Java que recibe datos y los transforma en el tipo de datos requeridos por la vista. 5.5.1 Selección de fechas En el menú principal, el usuario cuenta con tres formularios disponibles, mediante los cuáles puede seleccionar la fecha para la que quiere visualizar la gráfica. Así, es necesario elegir no solo la fecha, sino la hora concreta de inicio y de final, concretando así un intervalo para el cuál hacer una consulta a la base de datos. 64 conseguir que ningún agente externo pueda “inyectar” contenido malicioso en la aplicación web, protegiendo también la base de datos en MySQL para la persistencia de los datos recibidos. 6.2 Resultados gráficos y validación Una vez comentada toda al parte técnica del proyecto, es importante visualizar las gráficas obtenidas, para comprobar que los resultados empíricos se corresponden con los esperados de forma teórica. 6.2.1 Traspaso en la red móvil De forma general, el traspaso o transferencia [32] ocurre cuando la calidad de la conexión entre el dispositivo y la estación base [33] a la que está conectado es insuficiente para asegurar ciertos niveles. Además, están divididas en celdas hexagonales a lo largo de toda la superficie, por lo cuál, cuando nos desplazamos de la cercanía de una estación base a otra, ocurrirá este suceso que tiene lugar de forma invisible para el usuario del dispositivo móvil, asegurando así una conexión continua. Por ello, se puede comprobar que, si caminamos por la ciudad en determinadas zonas, habrá puntos de baja conexión en los que casi con total seguridad se realizará un cambio de estación base. A continuación, se muestra la gráfica de la potencia de la señal de la red móvil en un desplazamiento de un punto de la ciudad a otro caminando. Figura 50. Aplicación Web – Gráfica de la potencia de la señal de la red móvil. 65 Figura 51. Aplicación Web – Tabla de cambios de estación base en la red móvil. Como se puede observar, hay puntos rojos marcados en la gráfica. Se han marcado de este color los puntos que implican un cambio de celda: además, se puede comprobar que la mayoría de estos cambios hacen que, mientras que previo al cambio la potencia de la señal estaba empeorando, una vez sucedido comienza a mejorar de nuevo la calidad de la señal. Para facilitar la lectura de la información, en la zona de la derecha de la pantalla existe una tabla informativa que recoge el identificador del punto del que se muestran datos (según la cantidad de puntos marcados en rojo en la gráfica), junto con la fecha en la que se registró y los nuevos identificadores de la estación base con la que se está transmitiendo. Según un estudio de BEC Technologies [34], estos son los niveles de potencia de señal necesarios para la comunicación: Figura 52. Niveles de potencia de señal de la red móvil. Se puede comprobar que en la mayoría del tiempo, nos situamos en la zona de calidad “suficiente” o “buena” Estos valores no solo dependen de la calidad de la señal enviada desde la estación base, sino que hay otros muchos factores que pueden afectar: - Diferentes señales en la misma zona geográfica que puedan generar interferencias. - Barreras físicas (en especial, edificios o grandes vehículos circulando en las proximidades). - Condiciones climatológicas: puede variar la potencia de la señal en función de las nubes, lluvia.. A modo informativo, también se ha generado una gráfica circular donde se muestran todas las estaciones base con las que ha estado conectado el dispositivo, junto con el identificador de las mismas y el periodo de tiempo que ha permanecido conectado. 66 Figura 53. Aplicación Web – Estadísticas de estaciones base en la red móvil. 6.2.2 Traspaso en la red móvil Respecto al traspaso de la interfaz WiFi, es algo más complicado el estudio, ya que se necesitarían dos puntos de acceso a los que conectarse. Esto, por el momento, no es posible comprobarlo en mi casa. Donde sí podría comprobarlo es en la ETSI, pero debido a la reciente crisis sanitaria que estamos sufriendo, me ha sido imposible desplazarme a la facultad a comprobar si, efectivamente, se mide bien este suceso. Sin embargo, el procedimiento es el mismo: cuando ocurre un cambio de punto de acceso, el dispositivo móvil registra ese cambio enviándolo al servidor. Así, en el servidor se remarca ese punto rojo indicando que ha ocurrido el traspaso, registrándose también en una tabla en la zona de la derecha de la pantalla. Sin embargo, utilizando la red WiFi de mi casa y habilitando la conexión de la “Zona Wi-Fi Portátil” con la que se cuenta en la mayoría de dispositivos móviles, se ha emulado una segunda red con la cuál poder realizar pruebas. Figura 54. Aplicación Web – Gráfica de la potencia de la señal de la red WiFi. 67 Figura 55. Aplicación Web – Tabla de cambios de red WiFi. Como se puede ver, en el caso del WiFi es distinto: habiendo dos redes diferentes, el momento en el que cambia de un punto de acceso a otro es cuando no existe señal, es decir, cuando la potencia es de -127dBm. Sin embargo, aunque el objetivo del proyecto es la monitorización de la conectividad, puede servir como una base para controlar y mejorar estas características del dispositivo: mediante el envío de órdenes desde la aplicación Android, sería posible indicar al terminal que, en el caso de detectar una red disponible con mejor calidad de señal, cambiase a esa red para mejorar la conexión. Además, para poder haber hecho este estudio “aproximativo” sobre el cambio entre dos redes WiFi distintas, se ha tenido que modificar el código de las aplicaciones: si bien para distinguir entre un AP y otro se puede utilizar el BSSID, para distinguir entre dos subredes distintas se utiliza el SSID. A continuación, se muestra una tabla de referencia que según distintas fuentes consultadas, [35], [36], son los distingos niveles de calidad de la conexión: Figura 56. Niveles de potencia de señal de la red WiFi. 68 7 CONCLUSIONES Y LÍNEAS FUTURAS 7.1 Conclusiones personales El desarrollo de las distintas aplicaciones y el despliegue de Orion junto con sus componentes adicionales mediante Docker ha supuesto un reto a lo largo de la realización del proyecto, por los motivos que voy a exponer a continuación. En un principio, la idea que tenía sobre la estructura del proyecto era totalmente distinta. Sin embargo, a medida que he ido avanzando en el proyecto, he ido adquiriendo nuevas habilidades que me han permitido afrontar los problemas que iban surgiendo con mayor facilidad. Esto hizo que, junto con la ayuda de mi tutor, se haya ampliado el alcance del proyecto, añadiendo factores como la seguridad de la aplicación web y de los componentes de FIWARE. Mentiría si dijese que ha sido sencillo: aunque contaba con los conocimientos teóricos adquiridos a lo largo de la carrera, en este proyecto he mejorado la capacidad de autoaprendizaje. Tecnologías que hasta hace poco eran desconocidas, como Docker, o el uso de Spring Framework, han facilitado la tarea de despliegue de servicios y la programación en Java de la aplicación web desarrollada. Gracias a todas estas herramientas, he conseguido el objetivo del trabajo: desde la recolección de datos en un dispositivo móvil, hasta el envío y modelado de información para presentarlo a un usuario a través de una aplicación web (de forma segura). Sin embargo, aún hay ciertos aspectos que podrían, en mi opinión, ser mejorados para conseguir una solución mucho más efectiva y útil. 7.2 Conclusiones técnicas y líneas futuras En relación a la aplicación web junto con la aplicación Android, a lo largo del proyecto se ha conseguido monitorizar el dispositivo móvil de forma pasiva, recibiendo información del mismo y obteniendo resultados estadísticos en la aplicación web. Esto, sin duda alguna, ofrece al usuario información suficiente como para poder actuar en consecuencia y mejorar el rendimiento del dispositivo. Es por ello que se podrían ampliar las funcionalidades de estas dos aplicaciones, permitiendo al usuario interactuar con el dispositivo. Por ejemplo, si se estuviese monitorizando la interfaz WiFi del móvil, el usuario podría tener acceso a los ajustes para que, en caso de detectar un deterioro en la señal, forzar el cambio de punto de acceso para mejorar la calidad. En relación a los componentes de FIWARE (Orion, Wilma y Keyrock), se ha utilizado el primer nivel de seguridad, que es la autenticación. Sin embargo, aún están disponibles a través de estas dos herramientas otros dos niveles más avanzados: autorización básica y autorización avanzada. Mediante estos dos niveles, se pueden otorgar distintos permisos de acceso a los recursos en función del usuario que lo solicita. Así, determinados recursos solo estarían disponibles para cuentas con acceso privilegiado. Con este escenario, se podría hacer que la aplicación web solo tuviese los permisos necesarios para suscribirse a contenido, y no para la publicación de información, y que la aplicación Android, que actúa como sensor de monitorización, solo pudiese publicar contenido en Orion, sin la posibilidad de solicitar ningún recurso. Sobre los aspectos relativos a la seguridad, durante todo el proyecto se ha podido observar que el envío de información a través de la red se realiza a través de texto plano, utilizando el protocolo HTTP. Una mejora importante que podría ser aplicada al proyecto, podría ser la utilización de certificados para poder utilizar HTTPS. En este caso, la aplicación web envía el token aleatorio al servidor de contexto en la suscripción sin ningún 69 tipo de cifrado, por lo cuál cualquier atacante podría capturar el tráfico en la red y obtener del mensaje el token de acceso. Esto también se aplica a la solicitud del token a Keyrock, ya que lo envía en la respuesta en texto plano. Con respecto a la interfaz gráfica, tanto la aplicación web como la aplicación Android cuentan con los componentes básicos para poder interactuar con todas sus funcionalidades. En este aspecto, también se podrían mejorar, añadiendo gestión de usuarios, avisos mediante notificaciones… consiguiendo así una experiencia de usuario más completa y personalizada. 70 ANEXO A: HERRAMIENTAS UTILIZADAS En este anexo se detallan todas las herramientas utilizadas para el proyecto, tanto los IDEs elegidos para el desarrollo de las aplicaciones, como las tecnologías utilizadas. Entornos de Desarrollo utilizados Spring Tool Suite 4 Spring Tool Suite 4 (STS) es un entorno de desarrollo basado en la versión Java EE de Eclipse, que nos permitirá desarrollar aplicaciones basadas en Spring. Permite añadir fácilmente extensiones y módulos que nos ofrecen la posibilidad de personalizar la herramienta en función de nuestras necesidades. Hibernate, JPA y MySQL Hibernate, junto con JPA, se utiliza para realizar la conexión entre clases Java y datos relacionales. JPA es una API de persistencia de datos, desarrollada para Java EE. Ambas herramientas se han utilizado en la aplicación web para mapear los datos desde clases Java a las tablas de la base de datos y viceversa. Esto permite al usuario abstraerse de las consultas y actualizaciones a la base de datos utilizando simplemente clases en Java que realizan estas acciones. ChartJS Charts.js es una librería en Javascript, de código abierto, que permite dibujar gráficas de diversos tipos utilizando el elemento “canvas” de HTML5. Para este proyecto, se han utilizado gráficas lineares (con ejes cartesianos) y una gráfica circular para presentar estadísticas. Android Studio Android Studio es el entorno de desarrollo oficial para aplicaciones Android. Es un software de Código abierto basado en IntelliJ IDEA. A través de Android Studio, se ha desarrollado la aplicación Android encargada de monitorizar el dispositivo. De forma predeterminada, Android Studio cuenta con la opción de crear dispositivos virtuales sobre los que probar las aplicaciones desarrolladas, pero también ofrece la posibilidad de exportar la aplicación a un dispositivo físico. Tecnologías utilizadas Docker y Docker-compose Docker es una tecnología de código abierto que permite empaquetar en contenedores independientes distintas aplicaciones. De esta forma, se crea un contenedor con la aplicación deseada y se puede actuar de dos maneras. La primera de ellas, a través de diferentes contenedores, desplegar también las dependencias de la aplicación principal y conectarlas a través de las herramientas necesarias para ello. Otro método es encapsular en un mismo contenedor las dependencias de la aplicación y así desplegar de una sola vez la aplicación functional. Está escrita en el lenguaje de programación Go y se puede utilizar sobre Linux, Windows y macOS. 71 Docker Compose es una herramienta utilizada para ejecutar de manera ordenada y correcta multiples contenedores y así desplegar una aplicación junto con sus dependencias y conexiones. Permite a través de un fichero de configuración YAML establecer las dependencias necesarias para automatizar el despliegue. MongoDB y MySQL MySQL es utilizado tanto por Keyrock como por la aplicación web. La parte relativa a la aplicación web ya se ha comentado en la sección oportuna. Para el caso de Keyrock, MySQL, como gestor de bases de datos relacionales, se encarga de almacenar la información relativa a los usuarios, aplicaciones y sensores registrados así como de los permisos de cada uno de ellos en el sistema MongoDB es una base de datos distribuida, no relacional, basada en documentos. Almacena datos en formato BSON [9], especificación similar a JSON. Es utilizada por Orion para almacenar información de contexto recibida por los distintos sensores que envían datos. Cabe destacar que no almacena información histórica, sino que cuando se recibe un dato nuevo, sobreescribe el anterior, por lo que la información anterior, si se quiere almacenar, debe ser tratada de forma manual. 72 ANEXO B: RECURSOS UTILIZADOS A continuación, se van a listar todos los recursos, tanto software como hardware, utilizados para la realización del trabajo, mostrando sus características más relevantes para cumplir su finción. Xiaomi Redmi Note 7 El dispositivo que actuará como sensor IoT será el teléfono Xiaomi Redmi Note 7. Es necesario disponer de una tarjeta SIM con contrato vigente con alguna compañía de telefonía móvi (Vodafone ES, en este caso). Tendrá instalada la aplicación Android utilizada para la monitorización y enviará información relativa al dispositivo. Las características del dispositivo son las siguientes: - Procesador: Snapdragon 660 a 2GHz - RAM: 4GB - Almacenamiento: 64GB - Versión Android: Android 9 - Versión MIUI: MIUI Global 11.0.7 Máquina Virtual Ubuntu 18.04.03 LTS para Orion Para el despliegue de todos los componentes relativos a Orion y la seguridad del mismo, se ha utilizado una máquina virtual Ubuntu 18.04.03 ofrecida por el Departamento de Telemática. Esta máquina estará situada en una subred privada pero recibirá paquetes externos a través de reenvío de puertos. La dirección IP de la máquina virtual se asignará de forma estática obteniendo la 192.168.1.13. Así, se evitará tener que modificar la configuración si el protocolo DHCP otorga una dirección distinta en algún arranque. Si se quisiesen configurar estos elementos en una máquina con una dirección IP distinta, al haber hecho redirección de puertos desde el middlebox al equipo, simplemente habría que reconfigurar dentro de la configuración de nuestro router, modificando la dirección IP a la que se debe enviar la información. Máquina Virtual Ubuntu 18.04.03 LTS para STS Para el despliegue del Servicio Web desarrollado, se ha utilizado una máquina virtual Ubuntu 18.04.03 ofrecida por el Departamento de Telemática. Esta máquina también estará situada en una subred privada, que puede ser distinta a la anterior, y recibirá paquetes externos a través de un puerto configurado en la pasarela. La dirección IP asignada a la máquina virtual será la 192.168.1.22, estática. Como en la máquina anterior, el único paso a seguir para modificar la dirección IP a la que se envía la información es cambiando la configuración de reenvío del router. 73 ANEXO C: INSTALACIÓN Y CONFIGURACIÓN DE SPRING TOOL SUITE Instalación de Spring Tool Suite Lo primero para poder instalar Spring Tool Suite es instalar las dependencias. Con Java instalado en nuestro sistema, instalamos Maven (necesario para STS): sudo apt install maven Una vez instalado, descargamos de la página oficial de STS el archivo comprimido, con la versión actual: wget https://download.springsource.com/release/STS4/4.6.0.RELEASE/dist/e4.15/springtool-suite-4-4.6.0.RELEASE-e4.15.0-linux.gtk.x86_64.tar.gz En el caso de querer descargar la última versión disponible, acceder a https://spring.io/tools y pulsar en "LINUX 64-BIT": Figura 57. Descarga de Spring Tools 4. Se descargará en la carpeta desde donde se ejecute dicho comando. El archivo comprimido debe descomprimirse en /opt: sudo mv spring-tool-suite-4-4.6.0.RELEASE-e4.15.0-linux.gtk.x86_64.tar.gz /opt cd /opt sudo tar xfvz spring-tool-suite-4-4.6.0.RELEASE-e4.15.0-linux.gtk.x86_64.tar.gz Para iniciar STS, ejecutamos en la línea de comandos: /opt/sts-4.6.0.RELEASE/SpringToolSuite4 80 ejecutemos el comando. En nuestro caso, el fichero orion.yml es el que contiene toda la información necesaria para el despliegue. A continuación se muestra la configuración de cada uno de los contenedores y se destacan los campos más importantes. - Orion Context Broker Figura 63. Fichero orion.yml – orion. - image: se detalla la imagen Docker a descargar junto con la versión requerida - hostname: define el nombre dentro de la red creada - depends_on: indica las dependencias de arranque de servicios. Antes de levantarse este contenedor, se levantarán las dependencias. Para cerrar los contenedores, se cierran antes los que dependen de otros. - networks: establece la subred donde se encontrará el contenedor - expose: establece puertos que solo estarán disponibles dentro de los servicios definidos, no en la máquina donde se ejecuta (para comunicaciones internas) - ports: puertos que se van a abrir de cara al exterior, para que sean accesibles desde fuera - healthcheck: establece un comando para determinar si el contenedor está correctamente desplegado En este caso, como se puede ver, se ha configurado Orion Context Broker para estar disponible en el puerto TCP 1026. En cualquier caso, este puerto será inaccesible desde el exterior por lo que el acceso tendrá que realizarse desde el PEP Proxy. En los siguientes apartados, se limita la explicación de los parámetros a la parte de configuración, ya que la parte teórica se ha comentado previamente. 81 - Keyrock Figura 64. Fichero orion.yml – keyrock. - image: se utiliza la versión del contenedor 7.8.1 - depends_on: depende de MySQL, para manejar la información de credenciales, aplicaciones registradas… - ports: Keyrock está disponible a través del puerto 3005, tanto para la conexión con el PEP Proxy como para solicitar tokens de acceso desde los sensores a través del envío de credenciales. - IDM_DB_PASS_FILE: especifica la localización de la clave de acceso a la base de datos - IDM_DB_USER: especifica el usuario con acceso a la base de datos - IDM_ADMIN_USER: nombre del administrador de Keyrock - IDM_ADMIN_EMAIL: email con el que acceder a la configuración de Keyrock - IDM_ADMIN_PASS: contraseña definida para acceder a la configuración de Keyrock junto con el email. - secrets: permite el acceso al “secreto” del servicio 82 - Wilma (PEP Proxy) Figura 65. Fichero orion.yml – orion-proxy. - image: se utiliza la versión 7.8.1 - depends_on: depende del despliegue de Keyrock ya que realiza consultas con las credenciales de acceso recibidas para obtener una respuesta positiva o negativa. - PEP_PROXY_APP_HOST: especifica el nombre del servicio detrás de Wilma (Orion) - PEP_PROXY_APP_PORT: especifica el puerto TCP de la aplicación que protege - PEP_PROXY_IDM_HOST: especifica el nombre del Identity Management utilizado - PEP_PROXY_IDM_PORT: especifica el puerto TCP del Identity Management - PEP_PROXY_APP_ID: especifica el identificador de la aplicación registrada - PEP_PROXY_USERNAME: el usuario registrado en Keyrock para Wilma - PEP_PROXY_PDP: especifica el tipo de servicio que ofrece el Policy Decision Point 83 - Bases de datos necesarias: MongoDB y MySQL Figura 66. Fichero orion.yml – mongo-db. - ports: se dispone del puerto 27017 para el acceso a MongoDB Figura 67. Fichero orion.yml – mysql-db. - ports: se puede acceder al gestor de base de datos a través del puerto 3306 - volumes: se define donde se encuentran los archivos para el estado inicial de la base de datos (información expandida en el siguiente apartado) Los cinco contenedores se encuentran en la misma máquina virtual. De manera esquemática, el sistema final se puede representar como en la siguiente figura. 84 Figura 68. Contenedores dentro de la máquina virtual Con toda la configuración previamente indicada, la estructura de contenedores dentro de la máquina que los aloja queda de la siguiente manera: Figura 69. Conexión entre contenedores Como se puede ver, los cinco contenedores se encuentran en la misma subred virtual, con rango 172.18.1.0 – 172.18.1.255, y cada uno de los contenedores tiene asociado una dirección concreta (excepto mongoDB, cuyo comando --bind_ip_all implica que se asocie a todo el rango). Además, a través del atributo expose se han configurado puertos para la comunicación interna, pudiendo todos los contenedores intercambiar información entre ellos. Este sería el caso, por ejemplo, de cuando Wilma recibe una solicitud para publicar información en Orion. Entonces, Wilma generará un mensaje HTTP con dirección IP origen 172.18.1.10 y con dirección IP destino 172.18.1.9, enviando la información que reciba del exterior. 85 Estado inicial de la base de datos Cuando se despliegan los contenedores, se crea una instancia del gestor de bases de datos MySQL, con el fin de almacenar la configuración de las aplicaciones y de la seguridad relativa a Keyrock. Así, Keyrock dispone de un volumen persistente donde almacenar los tokens, las claves, usuarios permitidos… Para agilizar el despliegue del proyecto, se utiliza un fichero de órdenes .sql que introduce en la base de datos información inicial con la aplicación y los sensores dados de alta. Así, cabe destacar las siguientes inserciones que se han hecho en la base de datos: - Se ha introducido un usuario administrador con el nombre de Juan, que tendrá acceso a todas las aplicaciones que se registren: Figura 70. MySQL – tabla user. - Se ha registrado una aplicación en la que se introducirán los datos de los sensores que envían y reciben información de Orion: Figura 71. MySQL – tabla oauth_client. - Por último, se han dado de alta los sensores que solicitarán acceso a Orion mediante sus credenciales: Figura 72. MySQL – tabla iot. Así, la base de datos queda poblada inicialmente y tanto el dispositivo móvil como el servicio web tendrán acceso a Orion una vez se desplieguen los componentes. 86 ANEXO F: INSTALACIÓN Y CONFIGURACIÓN DE LA APLICACIÓN ANDROID Instalación de Android Studio Para instalar la aplicación Android, tendremos que tener primero en nuestro equipo Android Studio instalado. Se puede obtener la versión oficial desde el siguiente enlace: https://developer.android.com/studio Pulsando en el botón nos descargamos la versión oficial y podemos proceder a instalarla, aceptando las pantallas del instalador hasta obtener el ejecutable. Figura 73. Descarga de Android Studio. Una vez instalada correctamente, importamos el archivo comprimido AppMonitorización pulsando en File -> New… -> Import project y se nos abrirá en Android Studio el proyecto seleccionado. El siguiente paso es conectar el teléfono al ordenador para instalar la aplicación. Instalación de la aplicación en el dispositivo móvil Para ello, tendremos que habilitar las Opciones para desarrollador, habilitando también Depuración USB e Instalar vía USB. Una vez hecho esto, conectamos mediante el cable el móvil a un puerto USB del equipo con Android Studio abierto y lo detectará de forma automática. Una vez lo detecte y cargue correctamente, aparecerá el nombre del dispositivo arriba a la derecha. Figura 74. Conexión de dispositivo físico a Android Studio. Le damos al botón Play y se empezará a instalar la aplicación en nuestro dispositivo. Puede que nos pregunte si confiamos en el origen y en ese caso hacemos clic en Sí o Aceptar. Esperamos un par de minutos y la aplicación se abrirá automáticamente en el dispositivo. Una vez hecho esto, cerramos Android Studio, expulsamos la unidad de forma segura y ya aparecerá el icono de la aplicación en el dispositivo. 87 ANEXO G: ORDEN DE DESPLIEGUE DE LAS HERRAMIENTAS En este anexo se van a detallar los pasos a seguir para desplegar todas las herramientas necesarias para comenzar a monitorizar la conectividad del dispositivo móvil en tiempo real. El seguimiento de estos pasos en orden es imprescindible para el correcto funcionamiento del proyecto. Apertura de puertos para acceso a los servicios El despliegue de la aplicación web se ha hecho en una máquina virtual Ubuntu. Dicha máquina virtual está localizada en un equipo situado en una subred privada (en este caso, en la de mi casa). Esto, sin embargo, no nos permite concretamente cumplir dos objetivos: el primero de ellos, que cualquier usuario pueda acceder a la página web publicada para visualizer el contenido (gráficas, suscripciones…). El segundo de ellos, y más importante, es el de configurar una URL donde esperar las notificaciones de las suscripciones activas. Para que pueda ocurrir, se tiene que habilitar un puerto dentro de nuestro middlebox que tenemos en casa para que, cuando reciba un paquete a dicho puerto, lo reenvíe a la dirección IP privada de la máquina virtual y al puerto TCP 8080 (donde escucha Tomcat). Así, se ha habilitado el puerto 54321 (tanto TCP como UDP) para que los paquetes que lleguen a ese puerto se reenvíen a 192.168.1.22:8080/urlNotificacion. De la misma manera, Orion y todos sus componentes se desplegarán en otra máquina virtual, distinta a la anterior, que podrá estar en otra subred. En este caso, los puertos habilitados deben ser los siguientes: - El puerto TCP 1027, que será donde el PEP Proxy Wilma escuche peticiones de acceso a recursos de Orion. - El puerto TCP 3005, que es donde Keyrock (PDP) escuchará solicitudes de tokens de acceso mediante el envío de las credenciales oportunas. Hay que recalcar que el puerto TCP 1026 (donde escucha Orion de manera no segura) no estará expuesto al exterior. Así, todos los usuarios externos se verán obligados a utilizar Wilma para acceder a los recursos. La dirección IP de la máquina donde están desplegado estos componentes es la 192.168.1.13. Figura 75. Reenvío de puertos. 88 Arranque de Orion mediante Docker El primer componente que hay que desplegar es Orion junto con todos sus complementos para fomentar la seguridad. Gracias al fichero “services” ya comentado, simplemente habrá que situarse dentro de la carpeta “myDockerCompose” y ejecutar el siguiente comando: sudo ./services orion Una vez hecho esto, el mismo fichero nos avisará si se ha desplegado correctamente y podremos pasar al siguiente paso. Figura 76. Despliegue de Orion con todas sus dependencias Arranque del Servicio Web mediante STS Estando ya arrancado Orion, tendremos que averiguar la dirección IP de la máquina donde está desplegado. Esta dirección IP tendremos que añadirla a la variable “ip” dentro de la clase ServingWebContentApplication del servidor. Figura 77. Asignación de dirección IP de Orion a la Aplicación Web. Una vez añadida, hacemos clic derecho sobre la carpeta del proyecto y seguimos los pasos de la imagen. 89 Figura 78. Inicialización de la Aplicación Web. Comenzará a cargar el servidor y se ejecutará Tomcat en el puerto 8080, información que podremos obtener de la consola de Spring Tool Suite. Figura 79. Arranque de la Aplicación Web. Una vez arrancado el servicio, el usuario podrá configurar en la interfaz gráfica las suscripciones que quiera tener activas, recibiendo así la información seleccionada que envíe el dispositivo móvil cuando se ejecute la aplicación Android. Envío de información desde el dispositivo móvil Una vez realizados los dos apartados anteriores, ya estarán listos tanto Orion como el servidor web. Dicho esto, el usuario, cuando quiera monitorizar la conectividad del dispositivo, simplemente tendrá que utilizar los selectores del menú “Servicios” para comenzar a enviar información a Orion.