Contexto

En mi proyecto actual, tengo el requisito de validar que las solicitudes que llegan a GeoServer (2.3.0) están permitidas.

El proyecto contiene esos hechos:

• el cliente GS no puede proporcionar la información principal (la contraseña, por ejemplo), el propio GS no tiene conexión con un repositorio de usuario / rol

Entonces aprovechamos la oportunidad de usar el mecanismo de filtro de autenticación para verificar que:

• una solicitud válida (a una capa WFS específica) contiene un encabezado HTTP especial (digamos X-CUSTOM-VALID)
• Este encabezado es un mensaje codificado JSON que contiene suficiente información para validar el hecho de que la solicitud fue iniciada por un cliente que estaba conectado a un tercer sistema válido (un nombre de usuario, un secreto, cosas así)

Estado

La documentación nos dice que deberíamos poder hacerlo ...

Sin embargo, la documentación no aclara cómo crear dichos componentes y cómo deberían configurarse.

Depuración de GeoServer Logré encontrar que para configurar dicho filtro, se requiere un proveedor de autenticación dedicado. Eso, para tener un panel en la interfaz de administración web (bajo autenticaciones, en la lista de Filtros de autenticación)

Panel

Por lo tanto, mi código se compone de esos archivos:

• ProducteurAuthFilterPanel.java
• ProducteurAuthFilterPanelInfo.java
• ProducteurAuthenticationFilterConfig.java
• ProducteurAuthenticationFilterPanel.html

Es necesario agregar un panel en la interfaz de administración web. ProducteurAuthFilterPanelInfoestá pegando los otros dos junto con el ProducteurAuthenticationFilteraquí después (EL filtro ^^).

El ProducteurAuthenticationFilterConfigdeclara que en su constructor:

setClassName(ProducteurAnonymousAuthenticationProvider.class.getName());
setName("producteur");

Filtro (y proveedor)

Ahora, las clases necesitaban crear un filtro para ser incluido en una cadena (supongo):

• ProducteurAuthenticationFilter : la implementación del filtro se extiende GeoServerSecurityFiltere implementaGeoServerAuthenticationFilter
• ProducteurAnonymousAuthenticationProvider: de alguna manera requerido por el Panel (arriba) para definir el nuevo filtro
• ProducteurAuthenticationException: utilizado en AuthenticationEntryPoint (solo Http403ForbiddenEntryPoint por ahora)

Finalmente, los beans se definen así:

<bean id="yaanonymousFilterProvider" class="dgarne.java.geoserver.security.ProducteurAnonymousAuthenticationProvider"/>

<bean id="producteurAuthPanelInfo" class="dgarne.java.geoserver.security.ProducteurAuthFilterPanelInfo">
    <property name="id" value="security.producteurAuthFilter" />
    <property name="shortTitleKey" value="ProducteurAuthFilterPanel.short"/>
    <property name="titleKey" value="ProducteurAuthFilterPanel.title"/>
    <property name="descriptionKey" value="ProducteurAuthFilterPanel.description"/>
</bean>

Al final del juego, en la interfaz de administración web, tengo un nuevo elemento en el panel de filtro, y lo usé en la asignación predeterminada (consulte la imagen a continuación para obtener referencias):

Descripción del problema

Aquí estamos...

Ninguna de mis solicitudes WFS emitidas por un cliente (OpenLayers) que coinciden con la asignación predeterminada (/ **) pasa por el filtro definido. Durante la depuración descubrí que las cadenas de filtros definidas en el Contexto de primavera nunca incluyen mi definición, sino que siempre incluyen la clásica usando anónimo, resumen o básico ...

Pregunta

Entonces, ¿hay alguien capaz de señalarme con una (mucho ^^) documentación más completa sobre cómo tengo que hacerlo?

Lo hago mediante la implementación de un Proxy como este que podría verificar las credenciales de un usuario como iniciado sesión usando variables de sesión y solo les permite acceder a los recursos a los que tienen derecho, es decir: verifique la URL de las capas a las que se llama y niegue el acceso si el usuario no está autorizado para verlos.

Si desea restringir a los usuarios a un área o conjunto de características en particular, hay dos enfoques.

1. Use vistas SQL parametrizadas para controlar qué datos vería el usuario. Puede usar el Proxy para cambiar la url antes de pasarla a Geoserver con los parámetros específicos de ese usuario. También puede enviar los parámetros de vuelta a Openlayers a través de una llamada Ajax después de que el usuario esté autenticado y proporcionar los parámetros como parte de la llamada getMAP de WMS en OpenLayers. Los datos reales que se muestran podrían manejarse mediante la sustitución de Variable en SLD para filtrar los datos que se muestran o mediante el uso de Estilos externos en sus llamadas getMap de WMS para cambiar el SLD que un usuario usa para mostrar una capa determinada.

2. Use una llamada Ajax después de la autenticación de usuario para especificar extensiones de mapa para permitir que el usuario se mueva por un área específica. También puede usar layerVisibility () para restringir qué datos también se pueden mostrar.