...
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 , 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.
...
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 , 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. Pej: Digital Broker, Dataflow, Digital Twin Broker, Api Manager, Portal Open Data (CKAN)…
...
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 un reverse proxy como NGINX actuando de intermediario. Este proxy intercepta las peticiones REST y las redirige primero hacia un PEP-Proxy 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, 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.
...
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 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…).
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 se desea establecer permisos por rol.
...