Compatibilidad FIWARE NGSIv2 en la Onesait Platform

¿Qué es FIWARE?

FIWARE es una plataforma, impulsada por la Unión Europea, para el desarrollo y despliegue global de aplicaciones de Internet del Futuro. Se fundamenta en una arquitectura abierta, pública y libre así como de un conjunto de especificaciones que permita a los desarrolladores, proveedores de servicios, empresas y otras organizaciones desarrollar productos que satisfagan sus necesidades.

FIWARE proporciona un conjunto de componentes Open Source que pueden utilizarse junto con otros desarrollos para construir soluciones de manera rápida y económica.

Proporciona un API para la integración de componentes (FIWARE NGSI), que provee las capacidades de interoperabilidad, extensión y replicación.

Soporte FIWARE NGSI en la Onesait Platform

La Onesait Platform proporciona compatibilidad nativa para aplicaciones desarrolladas sobre la plataforma FIWARE, permitiendo que las aplicaciones que utilizan el estándar NGSI se puedan conectar para interoperar entre sí, y además poder utilizar el resto de capacidades de la plataforma (Cuadros de mando, capacidades analíticas, cálculo de KPIs, apificación de los datos, etc.).

El soporte nativo para el protocolo NGSI se consigue incorporando a la arquitectura de la Onesait Platform tres componentes de la arquitectura abierta FIWARE:

• Orion Context Broker
• Cygnus
• STH-Comet (Short Time History)

Resultando el siguiente diagrama de componentes en la Plataforma:

Las funcionalidades que cubre cada componente FIWARE incorporado en la Onesait Platform son las siguientes:

• Orion Context Broker:

Componente principal de cualquier solución FIWARE, se encarga de la gestión de la información de contexto de los sistemas y aplicaciones conectados a la Plataforma, permitiendo que puedan enviar, modificar, consultar y suscribirse a notificaciones de cualquier dato relativo al estado actual del sistema.

La gestión de la información se hace a través de entidades, que son representaciones de objetos modelados ontológicamente como Data Models.

Implementa la especificación OMA NGSI exponiendo un API RESTful del estándar NGSI v2. A través de este API, diferentes aplicaciones (context providers) conectadas al broker, pueden integrarse entre sí intercambiando información.

La información de contexto se persiste en el Semantic Datahub de la Plataforma, de manera que en cada momento refleje el estado actualizado del sistema.

• Cygnus:

La información de contexto gestionada por el Orion Context Broker es útil para conocer en cada momento el estado del sistema, reflejándose inmediatamente en este cualquier cambio. En una plataforma «data-centric» como la Onesait Platform, es también esencial almacenar todo el histórico de cambios en cualquier entidad gestionada por el Orion Context Broker, ya que esto permite hacer procesos analíticos, machine learning, construir cuadros de mandos con series históricas de datos, calcular KPIs, ofrecer datos abiertos a los ciudadanos…

Dentro del proyecto FIWARE, Cygnus es el conector encargado de proveer persistencia histórica a los datos de contexto gestionados por el Orion Context Broker.

Basado en Apache Flume, Cygnus proporciona un proceso distribuido que permite obtener todos los cambios en la información de contexto desde el Orion Context Broker, y comunicarlos a diferentes destinos:

1. Short Time Historic: Base de datos histórica para aplicaciones y sistemas NGSI
2. Digital Broker: Broker natívo de Onesait Platform, almacena la información en el semantic datahub, lista para ser explotada por los diferentes módulos de la plataforma (Api Manager, notebooks, dataflows, flow engine, BPM, dashboards, reports…) y desencadenar todos los procesos asociados en la plataforma a la ontología correspondiente.

• STH-Comet (Short Time Historic):

Proporciona a las aplicaciones y sistemas con interfaz REST NGSI, los datos históricos del contexto en forma de series temporales. Permite calcular y devolver datos, tanto en «bruto» como agregados por atributos, así como acotar temporalmente la franja de consulta.

La información histórica es persistida en el Semantic Datahub de la Plataforma por el agente correspondiente de Cygnus, de manera que STH-Comet se dedica en exclusiva a atender peticiones vía REST y resolver las consultas sobre la base de datos.

Compatibilidad NGSIv2

Como se ha comentado, la Onesait Platform incorpora en su arquitectura los elementos fundamentales del esquema FIWARE para permitir que aplicaciones y sistemas desarrollados bajo el estándar NGSIv2 se puedan conectar a la Plataforma para interoperar entre sí, así como para que la información que produzcan sea gestionada para explotarla con las capacidades propias de la Onesait Platform.

Más en detalle, el diagrama de integración en la Onesait Platform de estos componentes de FIWARE se describe a continuación:

Para las aplicaciones y sistemas que utilicen protocolo REST NGSI v2, bien mediante conexión directa (context providers), bien mediante un intermediario FIWARE de tipo IoT Agent que utilice protocolos REST, MQTT, AMQP, etc. en formatos Ultralight 2.0, JSON, etc. se mantiene intacta la interfaz REST.

Dicha interfaz REST, expuesta desde la capa de adquisición de la plataforma es la propia de los brokers:

• Orion Context Broker: Gestor de contexto de la plataforma.
• Short Time Historic Comet: Gestor de consultas históricas sobre el contexto.

A efectos de seguridad, estos dos brokers no se exponen directamente, sino a través de un proxy inverso NGINX, configurado interceptar las peticiones y delegar en el Identity Manager de la plataforma la comprobación del token OAuth 2 de las peticiones REST dirigidas al Orion Context Broker y al STH Comet y verificar si el cliente al que corresponde el token es válido y dispone de permiso para acceder a la entidad (ontología) sobre la que hace la petición.

Orion Context Broker, como gestor de contexto de la Plataforma, atiende las peticiones NGSI v2 para crear, consultar, modificar y eliminar entidades, así como para gestionar las suscripciones y notificaciones a cambios en el contexto. Mantiene toda la información actualizada en el Semantic Datahub de la Plataforma, donde se crea una base de datos para el contexto en la instancia de MongoDB.

Cygnus, como bus de persistencia de cambios en el contexto, tiene una doble tarea:

• Mantener para su consulta desde el broker STH Comet, el Short Time Historic con el histórico del contexto en el Semantic Datahub de la plataforma, donde se ha creado una base de datos para el STH en la instancia de MongoDB.
• Notificar al broker principal de la Plataforma (Semantic Broker de Onesait Platform) los cambios en el contexto para que este los traslade a las ontologías correspondientes a las entidades. De este modo se dispondrá de toda la información en la Plataforma, lista para ser explotada por las diferentes capacidades de la misma: Api manager, motor de KPIs, motor de informes, motor de Dashboards, Notebooks analíticos, Machine Learning, Dataflows, etc.

Para ello Cygnus, basado en Apache Flume, se suscribe a Orion Context Broker, para recibir notificaciones de cambios en el contexto y generar eventos que tras ser procesados y preparados, finalmente se envían al destino correspondiente (STH en MongoDB y Digital Broker).

Short Time Historic Comet, como motor de consultas históricas sobre el contexto, atiende las peticiones para consultar series temporales históricas sobre la base de datos STH alimentada previamente por Cygnus.

Compatibilidad de modelos entre FIWARE y la Onesait Platform

NGSI es un estandar abierto publicado por OMA (Open Mobile Alliance) para proporcionar un protocolo de interoperabilidad mediante la gestión centralizada e intercambio de lo que se conoce como información de contexto. La primera versión data de 2013 y en 2016 evolucionó a su segunda versión, NGSI v2, convirtiendo el estándar en RESTful, simplificando las operaciones, utilizando tipos de datos nativos del formato JSON, soportando tipos de datos GeoJSON y Datetime y enriqueciendo las operaciones soportadas por la primera versión.

El protocolo se basa en la gestión de entidades con sus correspondientes atributos y en el intercambio entre aplicaciones de la información de dichas entidades.

Una entidad es cualquier objeto de interés para una aplicación y está definido por un conjunto de atributos o propiedades:

Al conjunto de todas las entidades existentes en un momento dado, con sus correspondientes atributos actualizados al valor real es a lo que se conoce como contexto.

Por lo tanto, el elemento fundamental en una solución NGSI v2 es el broker o gestor de contexto, al que se conectan todas las aplicaciones (context providers) para mantener actualizadas en este las entidades con las que trabajan en el mundo real. Las aplicaciones interoperan entre sí al compartir el mismo contexto actualizado en el broker a través de las operaciones que provee para tener acceso al contexto.

Las operaciones contempladas por el estándar NGSI v2 permiten:

• Crear nuevas entidades en el contexto.
• Modificar atributos de una entidad para actualizar el contexto.
• Consultar y filtrar las entidades existentes en el contexto.
• Suscribirse a cambios en el contexto para ser notificado.
• Consultar todos los tipos de entidades existentes en el contexto y el detalle de sus atributos.
• Inserciones, actualizaciones y borrado en batch.

La Onesait Platform proporciona soporte el estándar NGSI v2 incluyendo en su arquitectura el conjunto de piezas del ecosistema FIWARE comentadas anteriormente. Esto facilita la integración de forma transparente de sistemas y aplicaciones desarrolladas siguiendo el estándar NGSI v2, con otras que se conectan a la plataforma a través de cualquier otro módulo de la capa de adquisición o de la capa de interoperabilidad.

La integración transparente tanto entre aplicaciones NGSI v2 como con el resto de utilidades de la plataforma es posible gracias a la semántica de las entidades utilizadas, que proporciona una interpretación univoca de los datos independiente de las aplicaciones.

Para ello, las entidades pertenecientes al mismo tipo de entidad se modelan como ontologías a través de su correspondiente Data Model. La plataforma proporciona un conjunto extensible de plantillas con diferentes Data Models siguiendo estándares de ámbitos como IoT, Smart Cities, Social Media, GSMA…

Los Data Model proporcionados en la Plataforma para crear ontologías que modelen entidades, son configurables y extensibles desde la administración del control panel, lo que permite que con un adecuado gobierno del dato todas las entidades del mismo tipo cumplan con los requisitos y restricciones establecidos previamente al diseñar el Data Model a partir del cual los desarrolladores darán de alta las ontologías.

Las ontologías en la Plataforma disponen de almacenamiento físico para los datos, tanto en tiempo real como histórico, en la base de datos elegida.

Todos los cambios en el contexto que afecten a entidades pertenecientes al tipo de datos modelado por una ontología, son reflejados de inmediato en la base de datos de la ontología, lo que proporciona integración transparente con otras aplicaciones conectadas a la Plataforma que utilicen dicha ontología, independientemente del broker o módulo de la plataforma que utilicen para conectarse. Por ejemplo: Digital Broker, Dataflow, Digital Twin Broker, Api Manager, Portal Open Data (CKAN), etc.

Seguridad NGSIv2 en Onesait Platform

Las piezas FIWARE integradas en la Plataforma (Orion Context Broker y STH Comet) que exponen interfaces a las aplicaciones, están securizadas utilizando el mismo modelo que el resto de componentes de la Onesait Platform.

Al tratarse de interfaces REST, la seguridad se realiza mediante protocolo OAuth 2 utilizando el propio Identity Manager de la Plataforma.

La arquitectura de securización es la propuesta por FIWARE. Los brokers no se exponen directamente a las aplicaciones, sino que se utiliza NGINX como proxy inverso actuando de intermediario. Este proxy intercepta las peticiones REST y las redirige primero hacia un PEP-Proxy (plugin en el Identity Manager de Onesait Platform) que extrae el token OAuth 2 de la petición, comprueba su validez en el servidor OAuth 2 configurado (Identity Manager) y verifica si el token es válido, si el usuario al que pertenece tiene privilegios sobre recurso accedido (entidad, presente en el path de la petición) y el modo de acceso (verbo http de la petición). En caso de ser una petición válida, el PEP-Proxy devuelve una respuesta con código 204 (No Content) y el reverse proxy NGINX deja pasar la petición al broker. En caso contrario, se devuelve un código 401 (Unauthorized) si el token OAuth 2 no es válido o 403 (Forbidden) si el usuario no dispone de acceso al recurso, de este modo el reverse proxy NGINX no deja pasar la petición al broker.

El Identity Manager de la Plataforma se ha extendido con un plugin que actúa como un PEP-Proxy de FIWARE, analizando el token recibido en cada petición a los brokers y verificando si dicho token es válido y si la operación sobre la entidad solicitada está permitida para el usuario al que pertenece el token.

La gestión de la seguridad de las aplicaciones que se conectan al Orion Context Broker y a STH Comet se realiza desde el propio control panel de la plataforma siguiendo las directrices estándar de Onesait Platform:

• Si la aplicación gestiona roles de aplicación, se da de alta un Realm para la aplicación, donde se registran los roles de aplicación, usuarios y rol o roles asociados a cada usuario. Por ejemplo, supongamos la gestión de alquiler bicicletas con tres tipos de emplazamientos conectados a la plataforma: Estaciones de alquiler, Almacenes y Talleres. De manera que podemos considerar cada uno como un rol, y cada emplazamiento concreto pertenecerá a uno o varios roles.

• La aplicación se da de alta como un proyecto de la Plataforma, al que se le asocian:
  • Usuarios: se pueden asociar uno a uno o en bloque asociando un Realm con sus correspondientes usuarios al proyecto.
  • Recursos: elementos dados de alta en la plataforma (Ontologías, Notebooks, Dataflows, Apis en Api Manager, etc.). Para cada recurso se indica el permiso que tiene sobre él cada usuario en el proyecto o cada rol de aplicación, si se ha asociado un Realm al proyecto y si se desea establecer permisos por rol.
• Una vez registrada la aplicación como un proyecto en el control panel de la plataforma cualquier usuario asociado a la misma puede identificarse utilizando el API REST OAuth 2 del Identity Manager, para solicitar un token de acceso. Este token será incluido en las peticiones REST NSGI v2 mediante la cabecera X-Auth-Token, para que el PEP-Proxy del Identity Manager realice las tareas de control de acceso para la operación solicitada.

El PEP-Proxy del Identity Manager de la Onesait Platform está preparado para proporcionar tres niveles de seguridad:

• Autenticación:

Verificando que el token OAuth 2 incluido en la cabecera X-Auth-Token es válido en el Identity Manager y pertenece a un usuario autenticado en la Plataforma.

• Autorización basada en permisos de usuario:

En este caso el PEP-Proxy analiza la petición REST NGSIv2 extrayendo:

1. Cabecera X-Auth-Token: token OAuth 2. Permite validar que se trata de un usuario autenticado, así como conocer la identidad del usuario.
2. Recurso accedido en el path de la petición REST: permite conocer la entidad (ontología) sobre la que se realiza la petición
3. Verbo HTTP: modo de acceso al recurso. Permite conocer el tipo de operación solicitada: Alta, Consulta, Modificación, Borrado.

Con esta información, el PEP-Proxy dentro del Identity Manager determina si el usuario está asociado a la aplicación (proyecto dado de alta en el control panel) y si dentro de dicho proyecto el usuario dispone del acceso solicitado en la petición a la entidad (ontología)

• Autorización avanzada basada en roles de aplicación:

Es idéntica a la autorización basada en permisos de usuario solo que en este caso, el proyecto dado de alta en el control panel para la aplicación, tiene asociado un Realm con roles propios de la aplicación, y los permisos sobre cada entidad (ontología) se han establecido a nivel de rol y no de usuario nominal, ya que los usuarios se han perfilado en el Realm con dichos roles desde el control panel.

De este modo, instalando un simple plugin compatible con FIWARE se utiliza la seguridad nativa de la plataforma para proporcionar a las aplicaciones nativas NGSI v2 control de acceso a la información en el Context Broker y el Short Time Historic.

✍🏻 Author(s)