Создать собственный фильтр аутентификации в GeoServer 2.3.0

10

контекст

В моем текущем проекте у меня есть требование проверить, разрешены ли запросы, поступающие в GeoServer (2.3.0).

Проект содержит эти факты:

  • клиент GS не может предоставить основную информацию (например, пароль), сам GS не связан с репозиторием пользователя / роли

Поэтому мы воспользовались возможностью использовать механизм фильтра авторизации, чтобы проверить, что:

  • допустимый запрос (к определенному слою WFS) содержит специальный заголовок HTTP (скажем, X-CUSTOM-VALID)
  • Этот заголовок представляет собой сообщение в кодировке JSON, содержащее достаточно информации для проверки того факта, что запрос был инициирован клиентом, который был подключен к действующей третьей системе (имя пользователя, секрет, и тому подобное)

Положение дел

Документация говорит нам , что мы должны быть в состоянии сделать это ...

Однако в документации не ясно, как создавать такие компоненты и как их следует настраивать.

Отладка GeoServer Мне удалось обнаружить, что для настройки такого фильтра требуется выделенный поставщик аутентификации. Это для того, чтобы иметь панель в интерфейсе веб-администратора (под аутентификациями, в списке фильтров аутентификации)

панель

Таким образом, мой код состоит из этих файлов:

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

Это необходимо для добавления панели в веб-интерфейсе администратора. ProducteurAuthFilterPanelInfoсклеивает два других вместе с ProducteurAuthenticationFilterбудущим ( фильтр ^^).

ProducteurAuthenticationFilterConfigЗаявляет , что в его конструкторе:

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

Фильтр (и поставщик)

Теперь классы должны были создать фильтр для включения в цепочку (я думаю):

  • ProducteurAuthenticationFilter : реализация фильтра, расширяющая GeoServerSecurityFilterи реализующаяGeoServerAuthenticationFilter
  • ProducteurAnonymousAuthenticationProvider: каким-то образом требуется Panel (выше) для определения нового фильтра
  • ProducteurAuthenticationException: используется в AuthenticationEntryPoint (пока только Http403ForbiddenEntryPoint)

Наконец, бобы определены так:

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

В конце игры в интерфейсе веб-администратора у меня появился новый элемент на панели фильтров, и я использовал его в сопоставлении по умолчанию (см. Изображение ниже для ссылок): введите описание изображения здесь

Описание проблемы

Мы здесь...

Ни один из моих запросов WFS, выданных клиентом (OpenLayers), которые соответствуют сопоставлению по умолчанию (/ **), не проходит через определенный Фильтр. Во время отладки я обнаружил, что цепочки фильтров, определенные в контексте Spring, никогда не включают мое определение, а всегда включают в себя классическую цепочку, использующую анонимный, дайджест или базовый ...

Вопрос

Так есть ли кто-нибудь в состоянии указать мне (гораздо ^^) более полную документацию о том, как я должен это сделать?

Энди Петрелла
источник

Ответы:

1

Я делаю это, внедряя прокси-сервер, подобный этому, который может проверять учетные данные пользователей, вошедших в систему с использованием переменных сеанса, и позволяет им получать доступ только к тем ресурсам, на которые он имеет право, т.е. проверяет URL-адрес вызываемых слоев и запрещает доступ, если пользователь не авторизован для их просмотра.

Если вы хотите ограничить пользователей определенной областью или набором функций, есть два подхода.

  1. Используйте параметризованные представления SQL, чтобы контролировать, какие данные увидит пользователь. Вы можете использовать Прокси-сервер для изменения URL-адреса перед его передачей в Geoserver с параметрами, специфичными для этого пользователя. Вы также можете отправить параметры обратно в Openlayers через Ajax Call после аутентификации пользователя и предоставить параметры как часть вызова WMS getMAP в OpenLayers. Отображаемые фактические данные могут обрабатываться путем подстановки переменных в SLD для фильтрации отображаемых данных или с помощью внешних стилей в вызовах getMap WMS для изменения SLD, которое пользователь использует для отображения данного слоя.

  2. Используйте Ajax Call после аутентификации пользователя, чтобы указать экстенты карты, чтобы позволить пользователю перемещаться только вокруг указанной области. Вы также можете использовать layerVisibility (), чтобы ограничить отображаемые данные.

Марк Купитт
источник