Seguridad OAuth2: autenticación y autorización

GeoNode interactúa con GeoServer a través de un mecanismo de seguridad avanzado basado en el protocolo OAuth2 y GeoFence. Esta sección es un recorrido por la configuración y la instalación de la seguridad avanzada de GeoNode y GeoServer.

Lo que veremos en esta sección es:

  • Introducción

  • GeoNode (Backend de seguridad):

    1. Autenticación de Django

    2. Configuración y configuración del kit de herramientas OAuth de Django

    3. Detalles sobre la configuración de seguridad de settings.py

  • GeoServer (Backend de seguridad):

    1. Subsistema de seguridad GeoServer

    2. Introducción al complemento de seguridad OAuth2 de GeoServer

    3. Configuración del Servicio de rol REST de GeoNode

    4. Configuración del Filtro de autenticación OAuth2 de GeoNode

    5. Las Cadenas de Filtros de Autenticación de GeoServer

    6. Introducción al complemento GeoFence, el marco de seguridad avanzado para GeoServer

  • Solución de problemas y funciones avanzadas:

    1. Problemas comunes y soluciones

    2. Cómo configurar puntos finales protegidos con HTTPS

    3. Funciones avanzadas de GeoFence

Introducción

GeoServer, es decir, el servidor backend geoespacial de GeoNode, es un servidor espacial que necesita usuarios autenticados para acceder a recursos protegidos o funciones de administración.

GeoServer admite varios tipos de mecanismos de autenticación y autorización. Estos sistemas se pueden conectar entre sí y GeoServer puede usarlos al mismo tiempo mediante el uso de una cadena de filtros. En pocas palabras, este mecanismo permite a GeoServer verificar los diferentes protocolos de autenticación y autorización uno por uno. GeoServer utiliza el primero que coincide para autorizar a los usuarios.

La autenticación de GeoNode se basa de manera predeterminada en el subsistema de seguridad de Django. La autenticación de Django permite a GeoNode administrar sus usuarios, grupos, roles y sesiones internos.

GeoNode tiene algunos componentes externos, como GeoServer o QGis Server, que son servicios enchufables e independientes, dedicados a la gestión de datos geoespaciales. Estos servicios externos tienen sus propios mecanismos de autenticación y autorización, los cuales deben ser sincronizados de alguna manera con los de GeoNode. Además, en la mayoría de los casos, y a menos que se configure específicamente para deshabilitarlo, estos servicios externos mantienen un acceso de seguridad alternativo que, por ejemplo, permite a GeoNode modificar el catálogo geoespacial de manera interna, o a un administrador del sistema tener acceso independiente y privilegiado a los servidores.

Antes de profundizar en cómo funcionan la Autenticación y Autorización (A&A) de GeoServer/GeoNode y cómo se pueden configurar para que funcionen correctamente con GeoNode, aclaremos rápidamente la diferencia entre los conceptos de Autenticación y Autorización.

Autenticación

La autenticación es el proceso de verificar la identidad de alguien mediante el uso de algún tipo de credenciales y un protocolo de enlace. Si las credenciales son válidas, comienza el proceso de autorización. El proceso de autenticación siempre pasa al proceso de autorización (aunque a menudo parezca que están combinados). Los dos términos se suelen utilizar como sinónimos, pero son dos procesos diferentes.

Para obtener más detalles y explicaciones sobre los conceptos de autenticación, eche un vistazo aquí.

Autorización

La autorización es el proceso de permitir a los usuarios autenticados acceder a recursos protegidos verificando sus roles y derechos con algún tipo de mecanismo o protocolo de reglas de seguridad. En otras palabras, permite controlar los derechos de acceso otorgando o denegando permisos específicos a usuarios autorizados específicos.

Backend de seguridad de GeoNode

Autenticación de DJango

El sistema de autenticación de Django maneja tanto la autenticación como la autorización.

El sistema de autenticación consta de:

  1. Usuarios

  2. Permisos: Indicadores binarios (sí/no) que designan si un usuario puede realizar una determinada tarea.

  3. Grupos: una forma genérica de aplicar etiquetas y permisos a más de un usuario.

  4. Un sistema de hash de contraseñas configurable

  5. Formularios y herramientas de visualización para iniciar sesión de usuarios o restringir contenido

  6. Un sistema backend conectable

El sistema de autenticación de Django pretende ser muy genérico y no ofrece algunas funciones que se encuentran comúnmente en los sistemas de autenticación web. Se han implementado soluciones para algunos de estos problemas comunes en paquetes de terceros:

  1. Comprobación de la solidez de la contraseña

  2. Limitación de los intentos de inicio de sesión

  3. Autenticación frente a terceros (OAuth, por ejemplo)

Nota

Para obtener más detalles sobre la instalación y configuración del sistema de autenticación de Django, consulte la guía oficial https://docs.djangoproject.com/en/5.0/topics/auth/.

GeoNode se comunica con GeoServer a través de autenticación básica, para configurar los datos y el catálogo de GeoServer.

Para hacer esto, debe asegurarse de que GeoNode conozca el usuario administrador interno y la contraseña de GeoServer.

Advertencia

Este debe ser un usuario interno de GeoServer con derechos de administrador, no uno de GeoNode.

Asegúrese de que las credenciales estén configuradas correctamente en el archivo settings.py

OGC_SERVER

Asegúrese de que la configuración de OGC_SERVER esté configurada correctamente.

Tenga en cuenta que las dos propiedades LOGIN_ENDPOINT y LOGOUT_ENDPOINT deben especificar los puntos finales de GeoServer OAuth2 (consulte los detalles a continuación). Los valores predeterminados 'j_spring_oauth2_geonode_login' y 'j_spring_oauth2_geonode_logout' funcionan en la mayoría de los casos, a menos que necesite algunos puntos finales específicos diferentes de los últimos. En cualquier caso, esos valores deben ser coherentes con la configuración del complemento GeoServer OAuth2.

En caso de duda, utilice los valores predeterminados que aparecen a continuación.

Los valores predeterminados son:

...
# OGC (WMS/WFS/WCS) Server Settings
# OGC (WMS/WFS/WCS) Server Settings
OGC_SERVER = {
    'default': {
        'BACKEND': 'geonode.geoserver',
        'LOCATION': GEOSERVER_LOCATION,
        'LOGIN_ENDPOINT': 'j_spring_oauth2_geonode_login',
        'LOGOUT_ENDPOINT': 'j_spring_oauth2_geonode_logout',
        # PUBLIC_LOCATION needs to be kept like this because in dev mode
        # the proxy won't work and the integration tests will fail
        # the entire block has to be overridden in the local_settings
        'PUBLIC_LOCATION': GEOSERVER_PUBLIC_LOCATION,
        'USER': 'admin',
        'PASSWORD': 'geoserver',
        'MAPFISH_PRINT_ENABLED': True,
        'PRINT_NG_ENABLED': True,
        'GEONODE_SECURITY_ENABLED': True,
        'WMST_ENABLED': False,
        'BACKEND_WRITE_ENABLED': True,
        'WPS_ENABLED': False,
        'LOG_FILE': '%s/geoserver/data/logs/geoserver.log' % os.path.abspath(os.path.join(PROJECT_ROOT, os.pardir)),
        # Set to name of database in DATABASES dictionary to enable
        'DATASTORE': '',  # 'datastore',
        'TIMEOUT': 10  # number of seconds to allow for HTTP requests
    }
}
...

Interacción A&A entre GeoNode y GeoServer

La instancia GeoServer utilizada por GeoNode, tiene una configuración particular que permite que los dos marcos interactúen correctamente e intercambien información sobre las credenciales y permisos de los usuarios.

En particular, GeoServer está configurado con una «Cadena de filtros» para autorización que utiliza los dos protocolos siguientes:

  1. Autenticación básica: este es el mecanismo de autenticación de GeoServer predeterminado. Utiliza rfc2617 - Autenticación de acceso básica y resumida para verificar las credenciales del usuario.

    En otras palabras, GeoServer toma un nombre de usuario y una contraseña codificada en Base64 <https://tools.ietf.org/html/rfc4648>`_ en los encabezados de solicitud HTTP y los compara con su base de datos interna (que, por defecto, es un archivo XML cifrado en el directorio de datos de GeoServer). Si las credenciales del usuario coinciden, GeoServer verifica la autorización a través de sus ``Servicios de rol (veremos esos servicios en detalle en la sección GeoServer (Backend de seguridad) a continuación).

    Nota

    GeoServer viene por defecto con admin y geoserver como el nombre de usuario y la contraseña de administrador predeterminados. Antes de poner GeoServer en línea, es imperativo cambiar al menos la contraseña del administrador.

  2. Autenticación OAuth2: este módulo permite a GeoServer autenticarse con el protocolo OAuth2. Si la autenticación básica falla, GeoServer recurre a ella utilizando GeoNode como proveedor OAuth2 de forma predeterminada.

Nota

Se pueden encontrar más detalles directamente en la documentación oficial de GeoServer en la sección «Cadena de autenticación»

Desde el lado del servidor de GeoNode, el servidor utilizará la autenticación básica con credenciales de administrador para configurar el catálogo de GeoServer. GeoNode debe poder acceder a GeoServer y GeoNode debe conocer las credenciales de administrador internas de GeoServer.

Desde el lado del frontend de GeoNode (navegador y GUI), el objetivo de la Autenticación es permitir que GeoServer reconozca como válido a un usuario que ya ha iniciado sesión en GeoNode, proporcionando una especie de mecanismo de SSO <https://en.wikipedia.org/wiki/Single_sign-on>_ entre las dos aplicaciones.

GeoServer debe conocer y poder acceder a GeoNode a través de HTTP/HTTPS. En otras palabras, un usuario externo conectado a GeoNode debe estar autenticado en GeoServer con los mismos permisos. Esto es posible a través del protocolo de autenticación OAuth2.

Mecanismo de autenticación de GeoNode/GeoServer

GeoNode como proveedor OAuth2 (OP)

OpenID Connect es un marco de identidad creado sobre el protocolo OAuth 2.0 que amplía la autorización de los procesos OAuth 2.0 para implementar su mecanismo de autenticación. OpenID Connect añade un mecanismo de descubrimiento que permite a los usuarios utilizar una autoridad externa de confianza como proveedor de identidad. Desde otro punto de vista, esto puede verse como un sistema de inicio de sesión único (SSO).

OAuth 2.0 es un marco de autorización que permite a los clientes acceder a un recurso con acceso restringido en nombre del propietario del recurso. OpenID Connect permite a los clientes verificar a los usuarios con una autenticación basada en un servidor de autorización.

Como OP, GeoNode podrá actuar como proveedor de identidad confiable, lo que permitirá que el sistema funcione en un entorno aislado y/o permitirá que GeoNode autentique a usuarios privados gestionados por el subsistema de autenticación local de Django.

GeoServer como entidad de confianza (RP) de OAuth2

Gracias a la Autenticación OAuth2, GeoServer puede recuperar la identidad de un usuario final directamente del proveedor OAuth2 (OP).

Con GeoNode actuando como OP, el mecanismo evitará el uso de cookies confiando, en cambio, en el protocolo seguro OAuth2.

Cómo funciona el protocolo OAuth2:

../../_images/oauth001.png

  1. La parte confiada envía la solicitud al proveedor de OAuth2 para autenticar al usuario final

  2. El proveedor OAuth2 autentica al usuario

  3. El proveedor de OAuth2 envía el ID token y el token de acceso a la parte confiada

  4. La parte que confía envía una solicitud al endpoint de información del usuario con el token de acceso recibido del proveedor OAuth2

  5. El endpoint de información del usuario devuelve las claims (afirmaciones).

Mecanismo de autorización de GeoNode/GeoServer

Sin embargo, permitir que GeoServer utilice un OAuth2 para actuar como un RP OAuth2 no es suficiente para asignar la identidad de un usuario a sus roles.

En el lado de GeoServer, todavía necesitaremos un RoleService que pueda comunicarse con GeoNode y transformar los tokens en un User Principal para ser utilizado dentro del propio subsistema de seguridad de GeoServer.

En otras palabras, después de una autenticación exitosa, GeoServer debe autorizar al usuario para saber a qué recursos puede acceder o no. Un RolService basado en REST del lado de GeoNode permite que GeoServer se comunique con GeoNode a través de ``REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`_ para obtener el usuario actual junto con la lista de sus Roles.

Sin embargo, conocer los Roles asociados a un usuario no es suficiente. La Autorización completa de GeoServer necesita captar un conjunto de Reglas de Acceso, asociadas a los Roles, para poder establecer qué recursos y datos son accesibles para el usuario.

La autorización de GeoServer se basa únicamente en roles, por lo tanto, para cada usuario autenticado también necesitamos saber:

  1. Los roles asociados a una sesión de usuario válida

  2. Los permisos de acceso asociados a un recurso GeoServer

El mecanismo de autenticación anterior permite a GeoServer obtener información sobre el usuario y sus roles, lo que aborda el punto 1.

En relación con el punto 2, GeoServer hace uso del complemento GeoFence Embedded Server. GeoFence es una aplicación web Java que proporciona un motor de autenticación/autorización avanzado para GeoServer utilizando la interfaz descrita aquí. GeoFence tiene su propia base de datos de reglas para la gestión de reglas de autorización y reemplaza el sistema de gestión de seguridad estándar de GeoServer implementando un sofisticado Resource Access Manager. Por último, pero no por ello menos importante, GeoFence implementa y expone una REST API que permite a los clientes remotos autorizados leer/escribir/modificar reglas de seguridad.

Las ventajas de utilizar este complemento son múltiples:

  1. Las reglas de autorización tienen una granularidad fina. Las reglas de seguridad son manejadas por GeoFence de manera similar a las de iptables y permiten definir restricciones de seguridad incluso en subregiones y atributos de capas.

  2. GeoFence expone una interfaz REST a su base de datos de reglas internas, lo que permite a los administradores externos actualizar las restricciones de seguridad de manera programática

  3. GeoFence implementa un mecanismo de almacenamiento en caché interno que mejora considerablemente el rendimiento bajo carga.

Interacción de GeoNode con GeoFence

GeoNode en sí mismo es capaz de gestionar y aplicar reglas de autorización en GeoServer a través de la API REST de GeoFence, actuando como administrador para GeoServer. GeoNode configura correctamente las reglas de GeoFence cada vez que es necesario, es decir, cuando se actualizan los permisos de un Recurso / Capa.

GeoServer debe conocer y poder acceder a GeoNode a través de HTTP/HTTPS. En otras palabras, un usuario externo conectado a GeoNode debe estar autenticado en GeoServer con los mismos permisos. Esto es posible a través de GeoNodeCoockieProcessingFiler.

Resumiendo tendremos diferentes formas de acceder a las capas de GeoNode:

  1. A través de GeoNode vía DJango Authentication y GeoNodeCoockieProcessingFiler; básicamente los usuarios disponibles en GeoNode también son válidos para GeoServer o cualquier otro backend.

    Advertencia

    Si un usuario de GeoNode tiene derechos de “administrador”, también podrá administrar GeoServer.

  2. A través del Subsistema de Seguridad de GeoServer, siempre será posible acceder a GeoServer usando su sistema de seguridad interno y usuarios, a menos que esté explícitamente deshabilitado (advertencia esto es peligroso, debe saber lo que está haciendo).

Veamos ahora en detalle cómo se configuran las piezas individuales y cómo se pueden configurar.

Configuración e instalación de DJango OAuth Toolkit

Como se indicó anteriormente, GeoNode utiliza el protocolo OAuth2 para todas las interacciones del frontend con GeoServer. GeoNode debe configurarse como un proveedor OAuth2 y proporcionar un ID de cliente y una clave Client Secret a GeoServer. Esto es posible habilitando y configurando el Complemento Django OAuth Toolkit.

Advertencia

GeoNode y GeoServer no funcionarán en absoluto si no se ejecutan los siguientes pasos en la primera instalación.

Configuración de seguridad predeterminada settings.py para OAuth2

Verifique nuevamente que el proveedor OAuth2 y el complemento de seguridad estén habilitados y que las configuraciones a continuación estén configuradas correctamente.

AUTH_IP_WHITELIST

La propiedad AUTH_IP_WHITELIST limita el acceso a los puntos finales del servicio de rol REST de usuarios/grupos a las únicas direcciones IP incluidas en la lista blanca. Una lista vacía significa “permitir todo”. Si necesita limitar las llamadas REST de “api” a solo algunas IP específicas, complete la lista de esta manera: AUTH_IP_WHITELIST = ['192.168.1.158', '192.168.1.159']

Los valores predeterminados son:

...
AUTH_IP_WHITELIST = []
...

INSTALLED_APPS

Para permitir que GeoNode actúe como un proveedor OAuth2, debemos habilitar la aplicación DJango oauth2_provider proporcionada por «Django OAuth Toolkit».

Los valores predeterminados son:

...
INSTALLED_APPS = (

    'modeltranslation',

    ...
    'guardian',
    'oauth2_provider',
    ...

) + GEONODE_APPS
...

MIDDLEWARE_CLASSES

La instalación de la aplicación DJango oauth2_provider no es suficiente para habilitar la funcionalidad completa. También necesitamos que GeoNode incluya entidades adicionales a su modelo interno.

Los valores predeterminados son:

...
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',

    # The setting below makes it possible to serve different languages per
    # user depending on things like headers in HTTP requests.
    'django.middleware.locale.LocaleMiddleware',
    'pagination.middleware.PaginationMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',

    # If you use SessionAuthenticationMiddleware, be sure it appears before OAuth2TokenMiddleware.
    # SessionAuthenticationMiddleware is NOT required for using django-oauth-toolkit.
    'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
    'oauth2_provider.middleware.OAuth2TokenMiddleware',
)
...

AUTHENTICATION_BACKENDS

Para permitir que GeoNode actúe como proveedor de OAuth2, debemos habilitar el backend de DJango oauth2_provider.backends.OAuth2Backend provisto por el «Django OAuth Toolkit». Observe también que debemos especificar los alcances del proveedor de OAuth2 y declarar qué generador utilizar para crear ID de cliente de OAuth2.

Los valores predeterminados son:

...
# Replacement of default authentication backend in order to support
# permissions per object.
AUTHENTICATION_BACKENDS = (
    'oauth2_provider.backends.OAuth2Backend',
    'django.contrib.auth.backends.ModelBackend',
    'guardian.backends.ObjectPermissionBackend',
)

OAUTH2_PROVIDER = {
    'SCOPES': {
        'read': 'Read scope',
        'write': 'Write scope',
        'groups': 'Access to your groups'
    },

    'CLIENT_ID_GENERATOR_CLASS': 'oauth2_provider.generators.ClientIdGenerator',
}
...

Configuración de administrador del kit de herramientas OAuth de Django

Una vez que settings.py y local_settings.py se hayan configurado correctamente para su sistema:

  1. Complete los pasos de configuración de GeoNode

    • Preparar el modelo

      python manage.py makemigrations
python manage.py migrate
python manage.py syncdb

    • Preparar los datos estáticos

      python manage.py collectstatic

    • Asegúrese de que la base de datos se haya rellenado con los datos predeterminados iniciales

      Advertencia

      Obsoleto este comando será reemplazado por migraciones en el futuro, así que tenga cuidado.

      python manage.py loaddata initial_data.json

    • Asegúrese de que exista un superusuario para su entorno

      Advertencia

      Obsoleto este comando será reemplazado por migraciones en el futuro, así que tenga cuidado.

      python manage.py createsuperuser

    Nota

    Lea los tutoriales básicos en la documentación de GeoNode Developer para obtener detalles sobre los comandos específicos y cómo usarlos.

  2. Iniciar la aplicación

    Inicie GeoNode según cómo se haya realizado la configuración; ejecute el modo de depuración a través de paver, o mediante un servidor HTTP como Apache2 HTTPD, Nginx u otros.

  3. Finalizar la configuración del proveedor OAuth2

    En primer lugar, debe configurar y crear una nueva aplicación OAuth2 llamada GeoServer a través del panel de administración de GeoNode

    • Acceda al panel de administración de GeoNode

      ../../_images/oauth002.png

    • Vaya a Django OAuth Toolkit > Aplicaciones

      ../../_images/oauth003.png

    • Actualice o cree la aplicación llamada GeoServer

      Advertencia

      El nombre de la aplicación debe ser GeoServer

      ../../_images/oauth004.png

      • ID de cliente; un código alfanumérico que representa el ID de cliente de OAuth2. El complemento OAuth2 de GeoServer utilizará este** valor.

        Advertencia

        En un entorno de producción es altamente recomendable modificar el valor predeterminado proporcionado con la instalación de GeoNode.

      • User; Busca el usuario admin. Su ID se actualizará automáticamente en el formulario.

      • Redirect uris; Es posible especificar aquí varios URI. Estos deben coincidir con los URI de las instancias de GeoServer.

      • Client type; seleccione `Confidential

      • Authorization grant type; Elija Authorization code

      • Client secret; un código alfanumérico que representa el secreto del cliente de OAuth2. El complemento GeoServer OAuth2 utilizará este** valor.

        Advertencia

        En un entorno de producción es altamente recomendable modificar el valor predeterminado proporcionado con la instalación de GeoNode.

      • Name; Debe ser GeoServer

Backend de seguridad de GeoServer

Subsistema de seguridad GeoServer

GeoServer cuenta con un subsistema de seguridad robusto, basado en Spring Security. La mayoría de las funciones de seguridad están disponibles a través de la interfaz de administración web.

Para obtener más detalles sobre cómo funciona esto y cómo configurarlo y modificarlo, consulte la guía oficial de GeoServer http://docs.geoserver.org/stable/en/user/security/webadmin/index.html

Al utilizar el directorio de datos de GeoServer que se incluye con la compilación de GeoNode, ya está disponible la siguiente configuración. Solo deberá actualizarla de acuerdo con su entorno (como direcciones IP y nombres de host, claves OAuth2 y cosas similares). Sin embargo, se recomienda leer atentamente todos los siguientes pasajes para comprender exactamente cómo se configuran los diferentes componentes e identificar fácilmente cualquier posible problema durante la implementación.

Los temas principales de esta sección son:

  1. Conexión al servicio de rol REST de GeoNode

  2. Configuración del filtro de autenticación OAuth2 de GeoServer

  3. Configuración de las cadenas de filtros de GeoServer

  4. Configuración y prueba del servidor GeoFence y reglas predeterminadas

Conexión al servicio de rol REST de GeoNode

Comprobaciones preliminares

  • GeoServer está en funcionamiento y tienes derechos de administrador

  • GeoServer debe llegar a la instancia GeoNode a través de HTTP

  • La dirección IP del host de GeoServer debe tener permiso para acceder a las API del servicio de rol de GeoNode (consulte la sección AUTH_IP_WHITELIST más arriba)

Configuración del servicio de rol REST de GeoNode

  1. Inicia sesión como admin en la GUI de GeoServer

    Advertencia

    En un sistema de producción recuerda cambiar las credenciales de administrador predeterminadas admin geoserver

    ../../_images/oauth005.png

  2. Accede a la sección Seguridad > Usuarios, Grupos, Roles

    ../../_images/oauth006.png

  3. Si aún no está configurado el servicio geonode REST role service, haz clic en Servicios de rol > Agregar nuevo

    Nota

    Este pasaje no es necesario si ya se has creado el servicio de rol REST de geonodo. En ese caso, se mostrará en la lista de servicios de rol.

    ../../_images/oauth008.png
    ../../_images/oauth007.png

  4. Si aún no está configurado el servicio geonode REST role service, selecciona AuthKEY REST - Role service from REST endpoint

    ../../_images/oauth009.png

  5. Crea o actualiza el servicio de rol REST geonode según corresponda

    ../../_images/oauth010.png

    • Name; Debe ser geonode REST role service

    • Base Server URL; debe apuntar a la URL base de la instancia de GeoNode (p. ej., http://<geonode_host_url>)

    • Roles REST Endpoint`; Ingresa /api/roles

    • Admin Role REST Endpoint; Ingresa /api/adminRole

    • Users REST Endpoint; Ingresa /api/users

    • Roles JSON Path; Ingresa $.groups

    • Admin Role JSON Path; Ingresa $.adminRole

    • Users JSON Path; Ingresa $.users[0].groups

    Una vez que todo esté configurado y funcione, elije el rol de administrador y el rol de administrador de grupo como ROLE_ADMIN

Permitir que GeoFence valide reglas con ROLES

Advertencia

Las siguientes instrucciones son diferentes según la versión de GeoServer que esté utilizando actualmente.

GeoServer 2.9.x y 2.10.x

  1. Acceda a la sección Seguridad > Configuración

    ../../_images/oauth011.png

  2. Seleccione el servicio de rol REST geonode como Servicio de rol activo

    ../../_images/oauth012.png

GeoServer 2.12.x y superior

Con las últimas actualizaciones del complemento GeoFence, este último ya no reconoce el servicio de rol desde la configuración predeterminada, sino desde el archivo geofence-server.properties.

Dicho esto, es importante que el servicio de rol Seguridad > Configuración se configure como predeterminado, para permitir que GeoServer siga la cadena de autorización estándar.

Por otro lado, deberás asegurarte de que el archivo geofence-server.properties bajo la carpeta $GEOSERVER_DATA_DIR/geofence, contenga las dos propiedades adicionales siguientes:

gwc.context.suffix=gwc
org.geoserver.rest.DefaultUserGroupServiceName=geonode REST role service

Configuración del filtro de autenticación OAuth2 de GeoServer

Ahora es necesario verificar que GeoServer pueda conectarse a proveedores OAuth2 (específicamente a GeoNode OP) y poder autenticar usuarios a través de él.

Comprobaciones preliminares

  • GeoServer está en funcionamiento y tienes derechos de administrador

  • GeoServer debe llegar a la instancia GeoNode a través de HTTP

  • SLos valores de Client ID y Client Secret de OAuth2 han sido generados en GeoNode y son conocidos

Configuración del filtro de seguridad OAuth2 de GeoNode

  1. Accede a la sección Seguridad > Autenticación

    ../../_images/oauth013.png

  2. Si aún no está configurado el Filtro de autenticación geonode-oauth2 - Authentication using a GeoNode OAuth2, haz clic en Filtros de autenticación > Agregar nuevo

    Nota

    Este pasaje no es necesario si ya se ha creado el geonode-oauth2 - Authentication using a GeoNode OAuth2. En ese caso, se mostrará entre la lista de filtros de autenticación.

    ../../_images/oauth015.png
    ../../_images/oauth014.png

  3. Si aún no está configurado el filtro de autenticación geonode-oauth2 - Authentication using a GeoNode OAuth2, seleccione GeoNode OAuth2 - Authenticates by looking up for a valid GeoNode OAuth2 access_token key sent as URL parameter

    ../../_images/oauth016.png

  4. Crea o actualiza geonode-oauth2 - Authentication using a GeoNode OAuth2 según corresponda

    ../../_images/oauth017.png

    • Name; Debe ser geonode-oauth2

    • Enable Redirect Authentication EntryPoint; se recomienda poner esto en False, de lo contrario GeoServer no le permitirá conectarse a su GUI de administración a través del Formulario sino solo a través de GeoNode

    • Login Authentication EndPoint; a menos que tengas necesidades específicas, manten el valor predeterminado /j_spring_oauth2_geonode_login

    • Logout Authentication EndPoint; a menos que tengas necesidades específicas, manten el valor predeterminado /j_spring_oauth2_geonode_logout

    • Force Access Token URI HTTPS Secured Protocol; debe ser False a menos que hayas habilitado una Conexión segura en GeoNode. En ese caso, deberás confiar en el Certificado de GeoNode en el almacén de claves JVM de GeoServer. Consulta los detalles a continuación

    • Access Token URI; Establece esto en http://<geonode_host_base_url>/o/token/

    • Force User Authorization URI HTTPS Secured Protocol; debe ser False a menos que hayas habilitado una Conexión segura en GeoNode. En ese caso, deberás confiar en el Certificado de GeoNode en el almacén de claves JVM de GeoServer. Consulta los detalles a continuación

    • User Authorization URI; Establece esto en http://<geonode_host_base_url>/o/authorize/

    • Redirect URI; establece esta opción en http://<geoserver_host>/geoserver. Esta dirección debe estar presente en Redirect uris of GeoNode OAuth2 > Applications > GeoServer (consulte más arriba)

    • Check Token Endpoint URL; Establece esto en http://<geonode_host_base_url>/api/o/v4/tokeninfo/

    • Logout URI; Establece esto en http://<geonode_host_base_url>/account/logout/

    • Scopes; A menos que tengas necesidades específicas, manten el valor predeterminado read,write,groups

    • Client ID; La clave alfanumérica ID de cliente generada por el GeoNode OAuth2 > Aplicaciones > GeoServer (ver arriba)

    • Client Secret; La clave alfanumérica Secreto del cliente generada por el GeoNode OAuth2 > Applications > GeoServer (ver arriba)

    • Role source; Para autorizar al usuario en GeoNode, seleccione Role service > geonode REST role service

Configuración de las cadenas de filtros de GeoServer

Los siguientes pasos garantizan que GeoServer pueda adoptar más métodos de autenticación. Como se indicó anteriormente, es posible autenticarse en GeoServer mediante diferentes protocolos.

GeoServer escanea la cadena de filtros de autenticación asociados a la ruta especificada y los prueba uno por uno secuencialmente. El primero que coincida con el protocolo y sea capaz de otorgar acceso al usuario, rompe el ciclo creando un User Principal e inyectándolo en el SecurityContext de GeoServer. El proceso de Autenticación, entonces, termina aquí y el control pasa al de Autorización, que intentará recuperar los Roles del usuario autenticado a través de los Servicios de Roles de GeoServer disponibles asociados al Filtro de Autenticación que otorgó el acceso.

Comprobaciones preliminares

  • GeoServer está en funcionamiento y tienes derechos de administrador

  • GeoServer debe llegar a la instancia GeoNode a través de HTTP

  • El filtro de autenticación geonode-oauth2 - Authentication using a GeoNode OAuth2 y el geonode REST role service se han configurado correctamente

Configuración de las cadenas de filtros de GeoServer

  1. Accede a la sección Seguridad > Autenticación

    ../../_images/oauth013.png

  2. Identifica la sección Cadenas de filtros

    ../../_images/oauth018.png

  3. Asegúrate de que la cadena de filtros «web» esté configurada como se muestra a continuación

    ../../_images/oauth019.png

    Advertencia

    Cada vez que modifiques una cadena de filtros, no olvides guardar la configuración de Autenticación. Esto debes realizarlo para cada cambio.

    ../../_images/oauth020.png

  4. Asegúrate que la cadena de filtros rest esté configurada como se muestra a continuación

    ../../_images/oauth021.png

    Advertencia

    Cada vez que modifiques una cadena de filtros, no olvides guardar la configuración de Autenticación. Esto debes realizarlo para cada cambio.

    ../../_images/oauth020.png

  5. Asegúrate que la cadena de filtros gwc esté configurada como se muestra a continuación

    ../../_images/oauth022.png

    Advertencia

    Cada vez que modifiques una cadena de filtros, no olvides guardar la configuración de Autenticación. Esto debes realizarlo para cada cambio.

    ../../_images/oauth020.png

  6. Asegúrate que la cadena de filtros «predeterminada» esté configurada como se muestra a continuación

    ../../_images/oauth023.png

    Advertencia

    Cada vez que modifiques una cadena de filtros, no olvides guardar la configuración de Autenticación. Esto debes realizarlo para cada cambio.

    ../../_images/oauth020.png

  7. Agrega los «Puntos finales de inicio de sesión de GeoNode» a la lista delimitada por comas de la cadena de filtros «webLogin»

    ../../_images/oauth024.png

    Advertencia

    Cada vez que modifiques una cadena de filtros, no olvides guardar la configuración de Autenticación. Esto debes realizarlo para cada cambio.

    ../../_images/oauth020.png

  8. Agrega los Puntos finales de cierre de sesión de GeoNode a la lista delimitada por comas de la cadena de filtros webLogout

    ../../_images/oauth025.png

    Advertencia

    Cada vez que modifiques una cadena de filtros, no olvides guardar la configuración de Autenticación. Esto debes realizarlo para cada cambio.

    ../../_images/oauth020.png

  9. Agregue los Puntos finales de cierre de sesión de GeoNode a la lista delimitada por comas del nodo XML formLogoutChain en <GEOSERVER_DATA_DIR>/security/filter/formLogout/config.xml

    Necesitarás un editor de texto para modificar el archivo.

    Nota

    Si el nodo XML <formLogoutChain> no existe en absoluto, crea uno nuevo como se especifica a continuación

    <logoutFilter>
  ...
  <redirectURL>/web/</redirectURL>
  <formLogoutChain>/j_spring_security_logout,/j_spring_security_logout/,/j_spring_oauth2_geonode_logout,/j_spring_oauth2_geonode_logout/</formLogoutChain>
</logoutFilter>

    Advertencia

    El valor j_spring_oauth2_geonode_logout debe ser el mismo especificado como Logout Authentication EndPoint en geonode-oauth2 - Authentication using a GeoNode OAuth2 anterior.

Configuración y prueba del servidor GeoFence y reglas predeterminadas

Para funcionar correctamente, GeoServer necesita que el complemento GeoFence Embedded Server esté instalado y configurado en el sistema.

La configuración de GeoServer proporcionada para GeoNode ya tiene el complemento instalado con una configuración predeterminada. En ese caso, verifica que el complemento funcione correctamente y que se hayan configurado las reglas predeterminadas siguiendo los pasos siguientes.

Comprobaciones preliminares

  • GeoServer está en funcionamiento y tienes derechos de administrador

  • El complemento GeoFence Embedded Server se ha instalado en GeoServer

Configuración de las cadenas de filtros de GeoServer

  1. Accede a la sección Seguridad > Autenticación

    ../../_images/oauth013.png

  2. Identifique la sección Proveedores de autenticación y asegúrate que el proveedor de autenticación geofence esté presente

    ../../_images/oauth032.png

  3. Asegúrate que la «Cadena de proveedores» esté configurada como se muestra a continuación

    ../../_images/oauth033.png

    Advertencia

    Cada vez que modifiques un proveedor de autenticación, no olvides guardar la configuración de Autenticación. Esto debe hacerse para cada cambio.

    ../../_images/oauth020.png

Configuración del servidor GeoFence y reglas

  1. Asegúrate que el servidor GeoFence funcione y que la configuración predeterminada esté configurada correctamente

    • Acceda a la sección Seguridad > GeoFence

      ../../_images/oauth026.png

    • Asegúrate que las Opciones estén configuradas de la siguiente manera y que el servidor funcione bien al realizar una Conexión de prueba

      ../../_images/oauth027.png

      • Allow remote and inline layers in SLD; Configúralo en True

      • Allow SLD and SLD_BODY parameters in requests; configúralo en True

      • Authenticated users can write; configúralo en True

      • Use GeoServer roles to get authorizations; configúralo en False

  2. Comprueba las reglas predeterminadas de GeoFence

    • Acceda a la sección Seguridad > Reglas de datos de GeoFence

      ../../_images/oauth028.png

    • Asegúrate que la regla DENY ALL esté presente de forma predeterminada, de lo contrario, sus datos serán accesibles para todos

      Nota

      Esta regla es siempre la última

      ../../_images/oauth029.png

      Advertencia

      Si esa regla no existe en la parte inferior (esta regla es siempre la última), agrégala manualmente.

    • Acceda a la sección Seguridad > Reglas de administración de GeoFence

      ../../_images/oauth030.png

    • Aquí no se necesitan reglas

      ../../_images/oauth031.png

Solución de problemas y funciones avanzadas

Problemas comunes y soluciones

  • GeoServer/GeoNode OAuth2 no se autentica como administrador, incluso utilizando los usuarios admin de GeoNode

    Síntomas

    Al intentar autenticarme con un usuario admin usando OAuth2, el proceso redirecciona correctamente a la página de GeoServer, pero no soy administrador de GeoServer.

    Causa

    Esto significa que, de alguna manera, GeoServer no pudo completar con éxito el proceso de autorización y autenticación.

    Las posibles causas del problema pueden ser las siguientes:

    1. La autenticación OAuth2 falla en el lado de GeoServer

      Generalmente, esto se debe a una excepción al intentar completar el proceso de autenticación.

      • Una causa típica es que GeoServer intenta utilizar conexiones HTTPS pero el certificado de GeoNode no es confiable;

        En ese caso, consulta la sección siguiente. También echa un vistazo a los registros (en particular, el de GeoServer) como se explica en Ejecuta el proyecto GeoNode por primera vez en modo DEBUG. Los registros de GeoServer deben contener una excepción detallada que explique la causa del problema. Si no se incluye ninguna excepción aquí (incluso después de haber elevado el nivel de registro a DEBUG), intenta verificar el servicio de rol de GeoNode como se explica a continuación.

      • Otro posible problema es que, de alguna manera, el protocolo de enlace OAuth2 no pueda completarse con éxito;

        1. Inicia sesión en GeoServer como administrador a través de su formulario de inicio de sesión WEB.

        2. Verifica nuevamente que todos los parámetros de geonode-oauth2 - Authentication using a GeoNode OAuth2 sean correctos. Si todo está bien, echa un vistazo a los registros (en particular, el de GeoServer) como se explica en Ejecuta el proyecto GeoNode por primera vez en modo DEBUG. Los registros de GeoServer deben contener una excepción detallada que explique la causa del problema. Si no se incluye ninguna excepción aquí (incluso después de haber elevado el nivel de registro a DEBUG), intenta verificar el servicio de rol de GeoNode como se explica a continuación.

    2. GeoServer no puede recuperar el rol del usuario desde un servicio de rol

      Verifica siempre el registro del servidor HTTP y del GeoServer como se especifica en la sección Ejecuta el proyecto GeoNode por primera vez en modo DEBUG. Esto podría guiarte directamente a la causa del problema.

      • Verifica que el host GeoServer tenga permiso para acceder a las API REST del servicio de rol GeoNode en AUTH_IP_WHITELIST de settings.py

      • Verifica que el geonode REST role service sea el servicio de rol predeterminado y que el complemento GeoServer OAuth2 se haya configurado para usarlo de manera predeterminada

      • Verifica que las API del servicio de rol REST de GeoNode funcionen y produzcan JSON correcto.

        Esto es posible utilizando simples llamadas GET con cUrl, como

        curl http://localhost/api/adminRole
$> {"adminRole": "admin"}


curl http://localhost/api/users
$> {"users": [{"username": "AnonymousUser", "groups": ["anonymous"]}, {"username": "afabiani", "groups": ["anonymous", "test"]}, {"username": "admin", "groups": ["anonymous", "test", "admin"]}]}

curl http://localhost/api/roles
$> {"groups": ["anonymous", "test", "admin"]}

curl http://localhost/api/users/admin
$> {"users": [{"username": "admin", "groups": ["anonymous", "test", "admin"]}]}

Cómo configurar puntos finales protegidos con HTTPS

En un sistema de producción, es una buena práctica cifrar la conexión entre GeoServer y GeoNode. Esto sería posible habilitando el protocolo HTTPS en las API de servicio de rol REST de GeoNode y los puntos finales de OAuth2.

La mayoría de las veces, dependerá de una conexión HTTPS autofirmada que utilice un certificado generado. Eso hace que la conexión no sea confiable y deberás indicarle a la máquina virtual Java de GeoServer que confíe en ella.

Esto puede hacerse siguiendo los pasos a continuación.

Si surge algún problema, consulta los registros (en particular, los de GeoServer) como se explica en Ejecuta el proyecto GeoNode por primera vez en modo DEBUG. Los registros de GeoServer deberían contener una excepción detallada que explique la causa del problema.

Certificados de confianza SSL

Al utilizar un Almacén de claves personalizado o intentar acceder a un proveedor OAuth2 protegido por SSL no confiable o autofirmado desde una conexión que no sea SSH, deberás agregar los certificados al Almacén de claves de JVM.

Para ello puedes seguir los siguientes pasos:

En este ejemplo vamos a

  1. Recuperar el certificado SSL del dominio GeoNode:

    «URI del token de acceso» = https://<geonode_host_base_url>/o/token/ por lo tanto, debemos confiar en https://<geonode_host_base_url> o (<geonode_host_base_url>:443)

    Nota

    Necesitarás obtener y confiar en los certificados de cada URL HTTPS diferente utilizada en los puntos finales de OAuth2.

  2. Almacenar certificados SSL en el disco duro local

  3. Agregar certificados SSL al almacén de claves de Java

  4. Habilita la JVM para verificar los certificados SSL desde el almacén de claves

  1. Recuperar el certificado SSL del dominio GeoNode

    Utiliza el comando openssl para volcar el certificado

    Para https://<geonode_host_base_url>

    openssl s_client -connect <geonode_host_base_url>:443
    ../../_images/google_ssl_001.png

  2. Almacenar el certificado SSL en el disco duro local

    Copia y pega la sección -BEGIN CERTIFICATE-, -END CERTIFICATE- y guárdala en un archivo .cert

    Nota

    Los archivos .cert son archivos de texto simple que contienen los caracteres ASCII incluidos en las secciones -BEGIN CERTIFICATE-, -END CERTIFICATE-

    geonode.cert (o cualquier nombre que desee con la extensión .cert)

    ../../_images/google_ssl_003.png

  3. Agregar certificados SSL al almacén de claves de Java

    Puedes usar el comando Java keytool de esta manera

    geonode.cert (o cualquier nombre que desee con la extensión .cert)

    keytool -import -noprompt -trustcacerts -alias geonode -file geonode.cert -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS}

    o, alternativamente, puedes utilizar alguna herramienta gráfica que te ayude a administrar los certificados SSL y los almacenes de claves, como Portecle

    java -jar c:\apps\portecle-1.9\portecle.jar
    ../../_images/google_ssl_005.png
    ../../_images/google_ssl_006.png
    ../../_images/google_ssl_007.png
    ../../_images/google_ssl_008.png
    ../../_images/google_ssl_009.png
    ../../_images/google_ssl_010.png
    ../../_images/google_ssl_011.png
    ../../_images/google_ssl_012.png
    ../../_images/google_ssl_013.png

  4. Habilita la JVM para verificar los certificados SSL desde el almacén de claves

    Para hacer esto, necesitas pasar una JAVA_OPTION a tu JVM:

    -Djavax.net.ssl.trustStore=F:\tmp\keystore.key

  5. Reinicia tu servidor

Nota

A continuación, encontrarás un script bash que simplifica la importación de certificados SSL de Keystore. Úsalo cuando te resulte conveniente.

HOST=myhost.example.com
PORT=443
KEYSTOREFILE=dest_keystore
KEYSTOREPASS=changeme

# get the SSL certificate
openssl s_client -connect ${HOST}:${PORT} </dev/null \
        | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ${HOST}.cert

# create a keystore and import certificate
keytool -import -noprompt -trustcacerts \
        -alias ${HOST} -file ${HOST}.cert \
        -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS}

# verify we've got it.
keytool -list -v -keystore ${KEYSTOREFILE} -storepass ${KEYSTOREPASS} -alias ${HOST}

Funciones avanzadas de GeoFence

Tutoriales y gestión de reglas de GeoFence

  • Este tutorial muestra cómo instalar y configurar el complemento Geofence Internal Server. Muestra cómo crear reglas de dos maneras: usando la interfaz gráfica de usuario y los métodos REST.

  • Las reglas de GeoFence se pueden crear, actualizar o eliminar a través de una API REST, a la que solo puede acceder un usuario administrador de GeoServer. Puede encontrar más detalles sobre cómo funciona la API REST de GeoFence aquí <https://github.com/geoserver/geofence/wiki/REST-API>`__.

Configuración de almacenamiento de reglas de GeoFence

De forma predeterminada, GeoFence está configurado para utilizar una base de datos basada en un sistema de archivos almacenada en el directorio de datos de GeoServer <GEOSERVER_DATA_DIR/geofence.

  1. Agregar Bibliotecas Java a GeoServer

    wget --no-check-certificate "https://maven.geo-solutions.it/org/hibernatespatial/hibernate-spatial-postgis/1.1.3.2/hibernate-spatial-postgis-1.1.3.2.jar" -O hibernate-spatial-postgis-1.1.3.2.jar
wget --no-check-certificate "https://repo1.maven.org/maven2/org/postgis/postgis-jdbc/1.3.3/postgis-jdbc-1.3.3.jar" -O postgis-jdbc-1.3.3.jar

cp hibernate-spatial-postgis-1.1.3.2.jar <GEOSERVER_WEBAPP_DIR>/WEB-INF/lib
cp postgis-jdbc-1.3.3.jar <GEOSERVER_WEBAPP_DIR>/WEB-INF/lib

restart geoserver

  2. Crea una base de datos con el esquema actualizado aquí o habilita la creación automática de hbm2ddl a través del archivo de configuración (consulte el paso 3)

    Nota

    Ten en cuenta que «update» también crea las tablas si no existen. Sin embargo, en producción, sugerimos cambiarlo a «validate»

    # If you want to create a new DB for GeoFence
sudo -u postgres createdb -O geonode geofence; \
sudo -u postgres psql -d geofence -c 'CREATE EXTENSION postgis;'; \
sudo -u postgres psql -d geofence -c 'GRANT ALL ON geometry_columns TO PUBLIC;'; \
sudo -u postgres psql -d geofence -c 'GRANT ALL ON spatial_ref_sys TO PUBLIC;'; \
sudo -u postgres psql -d geofence -c 'GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO geonode;'

  3. Agrega una configuración similar al ejemplo geofence-datasource-ovr.properties que aparece a continuación (si está cargada como extensión GeoServer)

    <GEOSERVER_DATA_DIR>/geofence/geofence-datasource-ovr.properties

    # /* (c) 2019 Open Source Geospatial Foundation - all rights reserved
#  * This code is licensed under the GPL 2.0 license, available at the root
#  * application directory.
#  */
#
geofenceVendorAdapter.databasePlatform=org.hibernatespatial.postgis.PostgisDialect
geofenceDataSource.driverClassName=org.postgresql.Driver
geofenceDataSource.url=jdbc:postgresql://localhost:5432/geofence
geofenceDataSource.username=postgres
geofenceDataSource.password=postgres
geofenceEntityManagerFactory.jpaPropertyMap[hibernate.default_schema]=public

################################################################################
## Other setup entries
################################################################################
## hbm2ddl.auto may assume one of these values:
## - validate: validates the DB schema at startup against the internal model. May fail on oracle spatial.
## - update: updates the schema, according to the internal model. Updating automatically the production DB is dangerous.
## - create-drop: drop the existing schema and recreates it according to the internal model. REALLY DANGEROUS, YOU WILL LOSE YOUR DATA.
## You may want not to redefine the property entirely, in order to leave the default value (no action).

geofenceEntityManagerFactory.jpaPropertyMap[hibernate.hbm2ddl.auto]=update
geofenceEntityManagerFactory.jpaPropertyMap[javax.persistence.validation.mode]=none
geofenceEntityManagerFactory.jpaPropertyMap[hibernate.validator.apply_to_ddl]=false
geofenceEntityManagerFactory.jpaPropertyMap[hibernate.validator.autoregister_listeners]=false

##
## ShowSQL is set to true in the configuration file; putting showsql=false in
## this file, you can easily check that this override file has been properly applied.

# geofenceVendorAdapter.generateDdl=false
# geofenceVendorAdapter.showSql=false

## Set to "true" in specific use cases
# workspaceConfigOpts.showDefaultGroups=false



################################################################################
## Disable second level cache.
## This is needed in a geofence-clustered environment.

#geofenceEntityManagerFactory.jpaPropertyMap[hibernate.cache.use_second_level_cache]=false

################################################################################
## Use external ehcache configuration file.
## Useful to change cache settings, for example diskStore path.
#geofenceEntityManagerFactory.jpaPropertyMap[hibernate.cache.provider_configuration_file_resource_path]=file:/path/to/geofence-ehcache-override.xml