Le contexte

Dans mon projet actuel, j'ai l'obligation de valider que les demandes venant de GeoServer (2.3.0) sont autorisées.

Le projet contient ces faits:

• le client GS ne peut pas fournir les informations principales (le mot de passe par exemple), GS lui-même n'a pas de connexion avec un référentiel utilisateur / rôle

Nous en avons donc profité pour utiliser le mécanisme de filtrage d'authentification afin de vérifier que:

• une demande valide (vers une couche WFS spécifique) contient un en-tête HTTP spécial (disons X-CUSTOM-VALID)
• Cet en-tête est un message codé JSON contenant suffisamment d'informations pour valider le fait que la demande a été initiée par un client qui était connecté à un troisième système valide (un nom d'utilisateur, un secret, des trucs comme ça)

Statut

La documentation nous dit que nous devrions pouvoir le faire ...

Cependant, la documentation n'est pas claire comment créer de tels composants et comment ils doivent être configurés.

Débogage de GeoServer J'ai réussi à trouver que pour configurer un tel filtre, il fallait un fournisseur d'authentification dédié. Cela, afin d'avoir un panneau dans l'interface d'administration Web (sous authentifications, dans la liste des filtres d'authentification)

Panneau

Ainsi mon code est composé de ces fichiers:

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

Ceux-ci sont nécessaires pour ajouter un panneau dans l'interface d'administration Web. ProducteurAuthFilterPanelInfocolle les deux autres avec le ProducteurAuthenticationFiltersuivant (LE filtre ^^).

Le ProducteurAuthenticationFilterConfigdéclare que dans son constructeur:

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

Filtre (et fournisseur)

Maintenant, les classes devaient créer un filtre à inclure dans une chaîne (je suppose):

• ProducteurAuthenticationFilter : l'implémentation du filtre s'étendant GeoServerSecurityFilteret implémentantGeoServerAuthenticationFilter
• ProducteurAnonymousAuthenticationProvider: requis par le Panel (ci-dessus) pour définir le nouveau filtre
• ProducteurAuthenticationException: utilisé dans AuthenticationEntryPoint (uniquement Http403ForbiddenEntryPoint pour l'instant)

Enfin, les beans sont définis comme suit:

<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>

À la fin du jeu, dans l'interface d'administration Web, j'ai un nouvel élément dans le panneau de filtrage et je l'ai utilisé dans le mappage par défaut (voir l'image ci-dessous pour les références):

Description du problème

Nous voilà...

Aucune de mes demandes WFS émises par un client (OpenLayers) qui correspondent au mappage par défaut (/ **) ne passe par le filtre défini. Lors du débogage, j'ai constaté que les chaînes de filtres définies dans le contexte de Spring n'incluaient jamais ma définition, mais incluaient toujours la classique utilisant anonymes, condensées ou basiques ...

Question

Alors, est-ce que quelqu'un peut me faire remarquer avec une documentation (beaucoup plus ^^) plus complète sur la façon dont je dois le faire?

Je le fais en implémentant un proxy comme celui-ci qui pourrait vérifier les informations d'identification d'un utilisateur comme connecté en utilisant des variables de session et leur permettre uniquement d'accéder aux ressources auxquelles ils ont droit, c'est-à-dire: vérifier l'URL pour les couches appelées et refuser l'accès si l'utilisateur n'est pas autorisé à les consulter.

Si vous souhaitez restreindre les utilisateurs à une zone ou à un ensemble de fonctionnalités particulier, il existe deux approches.

1. Utilisez les vues SQL paramétrées pour contrôler les données que l'utilisateur verrait. Vous pouvez utiliser le proxy pour modifier l'URL avant qu'elle ne soit transmise à Geoserver avec les paramètres spécifiques à cet utilisateur. Vous pouvez également renvoyer les paramètres à Openlayers via un appel Ajax après que l'utilisateur est authentifié et fournir les paramètres dans le cadre de l'appel getMAP WMS dans OpenLayers. Les données réelles affichées peuvent être gérées par substitution de variable dans SLD pour filtrer les données affichées ou en utilisant des styles externes dans vos appels getMap WMS pour modifier le SLD qu'un utilisateur utilise pour afficher une couche donnée.

2. Utilisez un appel Ajax après l'authentification de l'utilisateur pour spécifier les extensions de carte afin de permettre uniquement à l'utilisateur de se déplacer dans une zone spécifiée. Vous pouvez également utiliser layerVisibility () pour restreindre les données pouvant également être affichées.