Diseño¶

Servicio de Autenticación¶

El Servicio de Autenticación permite que los usuarios se identifiquen en la plataforma SITMUN. Tras la identificación, este servicio devuelve un token de acceso JSON web token (JWT) que permite al usuario acceder a los servicios de la plataforma. SITMUN almacena las contraseñas de los usuarios en la base de datos SITMUN usando un hash criptográfico (bcrypt). También está soportada la autenticación a través de un servidor LDAP. Hay que señalar que está planteado soportar la autenticación de usuarios a través de Active Directory (AD) y de certificados digitales.

Este servicio se expone vía la API de Autenticación.

Comportamiento esperado¶

El Servicio de Autenticación puede funcionar de dos formas distintas tras recibir la petición de un usuario.

uml diagram

El comportamiento espera es el siguiente:

Si no se configura el uso de un LDAP externo, el Servicio de Autenticación comprueba si el usuario y la contraseña son válidos en SITMUN y pasa al punto ④.
Si se configura el uso de un LDAP externo, el Servicio de Autenticación comprueba si el usuario y la contraseña son válidos en el LDAP externo.
Si el usuario es válido, el Servicio de Autenticación comprueba si el usuario es válido en SITMUN.
Si el usuario es válido en SITMUN, el Servicio de Autenticación genera un token de acceso que es devuelto al cliente.

Servicio de Configuración y Autorización¶

El Servicio de Configuración y Autorización se encarga de determinar qué puede hacer el Servicio de Proxy en cada petición realizada por un usuario. Si la petición no contiene el token de acceso del usuario, se asumirá que es una petición realizada para el usuario público.

Este servicio se expone vía la API de Configuración y Autorización.

Servicio de Proxy¶

Un componente clave del sistema es un proxy inverso que actúa como un intermediario entre los clientes de SITMUN y diversas fuentes de datos, como servicios web y bases de datos remotas, permitiendo controlar el acceso a la información, ya sea geográfica o no.

El proxy inverso es capaz de manejar peticiones a diversos tipos de servicios, incluyendo:

Servicios OGC Web Map Service (WMS), que ofrecen mapas en formato imagen usando peticiones HTTP GET.
Servicios OGC Web Map Tile Service (WMTS), que proporcionan mapas divididos en teselas (tiles) usando peticiones HTTP GET (codificación KVP).
Servicios OGC Web Feature Service (WFS), que permiten el acceso a datos geoespaciales vectoriales usando peticiones HTTP GET (codificación KVP).
Bases de datos relacionales que dispongan de un controlador (driver) JDBC (Java Database Connectivity). Las respuestas de las bases de datos se devuelven en formato JSON usando peticiones HTTP GET.

Para acceder a través del proxy, todas las peticiones deben incluir un token de acceso JWT, obtenido previamente a través de la API de autenticación, la cual identifica al usuario. La única excepción es el usuario denominado público, cuya autenticación es automática. Es decir, en caso de no incluir un token de acceso JWT, se asume que se trata del usuario público. Además, todas las peticiones enviadas a través del proxy deben incluir un identificador de territorio y un identificador de aplicación.

El proxy actúa como adaptador, traduciendo las peticiones de los clientes SITMUN a un formato adecuado para los servicios y datos subyacentes. Para realizar esta tarea, el proxy utiliza la API de configuración y autorización, que proporciona al proxy la información necesaria para construir las solicitudes a los servicios y adaptar las respuestas recibidas.

Ejemplos de uso del proxy son los siguientes:

El proxy permite a los clientes interactuar con servicios restringidos sin que el usuario tenga que conocer las credenciales o la URI de los mismos.
El proxy puede filtrar la información proporcionada por un OGC WMS, ocultando la parte que no corresponde al territorio indicado en la petición.

Este servicio se expone a través de la API de Proxy, que actúa como punto de entrada para las solicitudes relacionadas.

Comportamiento esperado¶

A continuación se muestra el comportamiento esperado del proxy.

uml diagram

El comportamiento esperado es el siguiente:

El visor de mapas hace una petición que es servida por el proxy.
El proxy realiza una petición a la API de configuración y autorización en el backend para obtener la configuración.
La API de configuración y autorización proporciona la configuración de la petición al servicio remoto al proxy.
El proxy compone una petición adecuada al servicio remoto y la envía.
El servicio remoto devuelve una respuesta.
Si es necesario, el proxy aplica una transformación a la respuesta.
El proxy devuelve la respuesta al visor de mapas.

Ejemplo: OGC WMS¶

Las peticiones a la API de Proxy tienen la siguiente forma:

GET /proxy/{appId}/{terId}/{type}/{typeId}?{keys*}
Authorization: Bearer {JWT token}

Lo que permite identificar:

appId: identificador de la aplicación que realiza la petición.
terId: identificador del territorio en el que se realiza la petición.
type: tipo de servicio que se solicita.
typeId: identificador del servicio que se solicita.
keys: parámetros adicionales que se envían al servicio.
token: token de autenticación JWT.

Por ejemplo, la siguiente petición correspondería con la petición de acceso a un servicio de mapas remoto:

GET /proxy/1/34/wms/1?SERVICE=WMS&REQUEST=GetMap
    &LAYERS=SITMUN
    &FORMAT=image/png
    &TRANSPARENT=true&VERSION=1.1.1&SRS=EPSG:25831
    &BBOX=405913.25142303,4593667.2516974,411183.74857697,4599953.7483026
    &WIDTH=498&HEIGHT=594
Authorization: Bearer SOME-TOKEN

La petición que el proxy realizaría al endpoint /api/config/proxy de la API de configuración y autorización sería:

{
  "appId": 1,
  "terId": 34,
  "type": "wms",
  "typeId": 1,
  "method": "GET",
  "parameters": {
    "SERVICE": "WMS",
    "REQUEST": "GetMap",
    "LAYERS": "SITMUN",
    "FORMAT": "image/png",
    "TRANSPARENT": "true",
    "VERSION": "1.1.1",
    "SRS": "EPSG:25831",
    "BBOX": "405913.2514230,4593667.251697,411183.7485769,4599953.748302",
    "WIDTH": "498",
    "HEIGHT": "594"
  },
  "id_token": "SOME-TOKEN"
}

La respuesta podría ser como sigue:

{
  "type": "wms",
  "exp": 1623340800,
  "payload": {
    "uri": "https://geoserveis.icgc.cat/icgc_bm5m/wms/service",
    "method": "GET",
    "vary": [
      "BBOX"
    ],
    "parameters": {
      "SERVICE": "WMS",
      "REQUEST": "GetMap",
      "LAYERS": "01_NIVJERARQUIC_LN,02_TIPUSLINIA_LN",
      "FORMAT": "image/png",
      "TRANSPARENT": "true",
      "VERSION": "1.1.1",
      "SRS": "EPSG:25831",
      "BBOX": "405913.2514230,4593667.251697,411183.7485769,4599953.748302",
      "WIDTH": "498",
      "HEIGHT": "594"
    }
  }
}

La petición a realizar por el proxy debe:

Ser a la URI indicada en el campo uri de la respuesta.
Con el método HTTP indicado en el campo method de la respuesta.
Con los campos y valores indicados en el campo parameters de la respuesta.
Con los campos y valores indicados en el campo vary de la petición del visor de mapas.

Es decir:

GET /icgc_bm5m/wms/service?SERVICE=WMS&REQUEST=GetMap
    &LAYERS=01_NIVJERARQUIC_LN,02_TIPUSLINIA_LN
    &FORMAT=image/png
    &TRANSPARENT=true&VERSION=1.1.1&SRS=EPSG:25831
    &BBOX=405913.25142303,4593667.2516974,411183.74857697,4599953.7483026
    &WIDTH=498&HEIGHT=594
Host: geoserveis.icgc.cat