Российской федерации (минэкономразвития россии)

Скачать 1.33 Mb.

Название	Российской федерации (минэкономразвития россии)
страница	11/13
Тип	Реферат

filling-form.ru > бланк доверенности > Реферат

1 ... 5 6 7 8 9 10 11 12 13

4.7.4. Управление защищёнными сервисами

4.7.4.1.Просмотр защищенных сервисов

Сервисы, которые будут защищёны securityManager, создаются и управляются на закладке Администратора Защищённые сервисы (Protected Services).

Столбцы таблицы содержат следующую информацию:

Имя: имя сервиса, данное Администратором для этого сервиса. Имя включено в URL, созданный securityManager для сервиса.
Активный: устанавливает, является ли сервис активным, т.е. готовым к использованию, или неактивным, т.е. недоступным.
Тип: тип сервиса (WMS, WFS, WFS-T, WCS, ARCGIS-SERVER, ARCIMS, URL)
URL защищённого сервиса: URL сервиса, который будет защищён.

Внимание! securityManager не может предотвратить прямой доступ к этому URL. Администратор решает, нужно ли обеспечивать безопасность. Более подробно см. Раздел под заголовком 'Защита от прямого доступа' в приложениях к этому документу.

Методы аутентификации: методы аутентификации, сконфигурированные для данного шлюза(WSS, httpauth, guest, saml).
Группа: имя группы, которой принадлежит данному шлюзу. Все sM_Administrators sM_Group Administrators группы могут редактировать этот шлюз.
Changed by: имя пользователя, внесшего последние изменения в данном шлюзе.
Changed at: отметка времени последнего изменения

4.7.4.2.Редактирование защищённых сервисов

Щёлкните на имени сервиса в виде Protected Services, чтобы открыть диалоговое окно Change.

В этом диалоговом окне вам доступны следующие параметры:

Активный: если вы поставите или уберёте отметку в этом окошке, будет активирован или дезактивирован сервис. Если отметка не стоит, конфигурация сервиса и связанные права всё ещё существуют, но доступ невозможен.
Описание: здесь можно добавить описание сервиса.
Тип: здесь можно выбрать тип сервиса. Доступны: WMS, WFS, WFS-T, WCS, ARCGIS-SERVER, ARC-IMS и URL.
URL защищённого сервиса: это URL, где можно получить доступ к защищённым сервисам. Внимание! Изменения, внесённые в этот URL, будут отражать любые policy models, созданные для этого неэффективного сервиса, поскольку они также содержат (неизменённый) URL сервиса.
Методы аутентификации: securityManager поддерживает различные типы аутентификации. Можно активировать и дезактивировать отдельные методы, используя соответствующие флаговые кнопки. Поддерживаются следующие методы аутентификации:

WSS: аутентификация с помощью протокола Web Security Service. Она, прежде всего, предназначена для использования со шлюзом или sdi.suite mapClient.
httpauth: аутентификация с помощью HTTP Basic Authentication: Этот протокол поддерживается многими стандартными клиентскими приложениями (включая системы веб-браузера и desktop GIS). Внимание! При использовании HTTP Basic Authentication настоятельно рекомендуется использовать только HTTPS, поскольку в противном случае логин пользователя будет передан открытым текстом.
saml: аутентификация с помощью SAML tickets (SAML Assertion Consumer Service). Этот интерфейс позволяет использовать расширенную интеграцию в случае single sign-on scenarios.
guest: используется для установки гостевого шлюза. Данный шлюз может быть вызван полностью без аутентификации. Логин автоматически сопровождается ролью 'guest'.

Впоследствии, необходимо указать группу, которой присвоен данный шлюз, кто и когда её создал, а также кто и когда вносил изменения. Соединение делается в целях присвоения набора политик.

Кнопки в конце диалогового окна используются для сохранения изменений, удаления сервиса (обратите внимание, что сохраняются соответствующие наборы политик), создания шлюза для этого сервиса (см. раздел 'Управление ') и возвращения в предыдущее диалоговое окно.

4.7.4.3.Создание нового защищённого сервиса

Можно добавить другую запись, используя кнопку «Создать» (Create) на закладке «Защищённые сервисы» (Protected Services). Записи, которые должны быть сделаны здесь, описаны в предыдущем разделе.

4.7.4.4.Доступ для администраторов группы

Администраторы группы также могут получить доступ к закладке «Защищённые сервисы» (Protected Services) в Администраторе securityManager. Однако отображаются только те сервисы, которые принадлежат группе администратора группы.

4.7.5.Управление правами

Администратор securityManager учитывает обслуживание политики, используемой WSS при тестировании авторизации для защищённых сервисов.

Администратор поддерживает политику доступа в качестве так называемых наборов политик. Эти наборы политик формируют политику для конкретного защищённого сервиса, они имеют определённую форму. Установленная версия securityManager содержит следующие типы: WMS, WFS, WFS-T, ArcIMS, ArcGIS Server, INSPIRE View Service, INSPIRE Feature Download Service и URL. Также возможно установить дополнительные типы с соответствующими плагинами.

Набор политик устанавливается для каждого сервиса в области управления «Политики» Администратора. В этом наборе содержаться все политики, имеющие отношение к сервису и его присвоению ролям (и тем самым владельцам). Содержание, атрибуты и опции настройки, доступные для набора, зависят от типа сервиса. Политика, используемая securityManager, всегда является комбинацией следующих пунктов:

Ресурсы: объекты, которые будут защищены от несанкционированного доступа; зависящие от типа, например, URL защищённого сервиса, слоя, типа пространственных объектов)
Действия: операции, которые могут быть выполнены на ресурсах; зависят от типа, например, GetMap, GetCapabilities, GET_IMAGE
Объекты: Объекты, которые получают доступ к ресурсу с помощью определенных действий; в securityManager на объекты ссылаются роли.

Менеджер политик (The policy manager of the securityManager) – это так называемая 'закрытая, положительная система'. Это означает, что все разрешения должны быть сформулированы как политики (положительные). Если WSS не в состоянии разместить политики для сервиса, доступ полностью блокируется. Любые запросы, на которые невозможно ответить однозначно на основе сформированных политик, считаются запрещенными (отклоняются).

Следующий раздел представляет пример создания набора политик с несколькими политиками для безопасного WMS.

4.7.5.1.Пять шагов создания набора политик для WMS

1) Создание набора политик и загрузка ресурсов

Откройте Администратор и выберите Policy Management. В дереве выберите узел WMS и щёлкните слева на Create New Policy Set.

В открывшемся диалоговом окне вы можете задать заголовок и дать описание набора политик WMS, который будет защищён. Заголовок будет показан в дереве политик для помощи в быстром размещении набора политик для конкретного сервиса. Для предоставления информации о цели набора политик должно использоваться описание. Выберите сервис в окошке Защищённый сервис (Protected Service), который вы ранее сконфигурировали на закладке Защищённые сервисы (Protected Services). Или, выберите Others в окне выбора и введите URL в поле WMS URL вручную.

Затем щёлкните на Получить слои (Get Layers). Это приведёт к тому, что на сервис будет отправлен запрос GetCapabilities. В случае успеха сервис загружается (через URL) вместе с его слоями в качестве источников. Созданные впоследствии политики могут обращаться к этим ресурсам. Затем отображён обзор доступных ресурсов (слоёв) наряду со средствами создания и редактирования прав для этого сервиса.

Внимание! рекомендуется срочно создать один набор политик для каждого защищённого сервиса, поскольку наличие нескольких наборов политик на один защищённый сервис может привести к неожиданному поведению программы. По этой причине securityManager выдаст предупреждающее сообщение, если предпринимаются попытки сохранить набор политик для сервиса, для которого уже определён другой набор политик. Однако, не смотря на это, securityManager допускает определение нескольких наборов политик для каждого сервиса.

2) Определение неограниченного доступа для роли Internal

Для этого примера необходимо, чтобы в менеджере пользователя была создана роль 'Internal' и чтобы она была присвоена хотя бы одному пользователю.

Чтобы создать политику в пределах нового набора политик, щёлкните Новый (New) в области Policies. В открывшемся диалоговом окне введите имя и описание создаваемой политики. Рекомендуется выбирать имена так, чтобы сразу было понятно, кто пытается получить доступ к какому ресурсу с этой политикой, например, 'Internal_allowed_all' или 'External_allowed_all_except_GetFeatureInfo'. Чтобы дать более подробное описание политики, можно также использовать поле Описание (Description).

Первое, что нужно сделать - это установить роли, к которым будет применяться эта политика. Если не стоит отметка для опции «Все роли» (All Roles), отображаются доступные роли.

Следующий шаг - определение ресурсов безопасного сервиса, для которого применяется эта политика. Если выбрана опция «Все ресурсы» (All Resources), относительно ресурсов нет никаких ограничений, а отдельные слои не отображаются в интерфейсе Администратора. Если снять отметку, будут отображены отдельные ресурсы, их можно будет выбирать в отдельности.

Примечание: URL безопасного сервиса является частью ресурсов для всех типов наборов политик. Если вы не включите этот ресурс в выборку, доступ всегда будет отклонён напрямую.

Теперь определите действия, для которых будет применяться данная политика. Как правило, действия доступны в соответствии с операциями, которые могут быть выполнены на сервисе данного типа. В случае WMS это: GetMap, GetCapabilities и GetFeatureInfo. Опять же, в этом случае вы сможете определить, будет ли право предоставлено для всех или для отдельных действий, щёлкнув на соответствующей опции.

В разделе Obligations, вы можете установить обязательства, с которыми связана политика. Чтобы установить отображение уведомления об авторском праве, см. следующий шаг по созданию второй политики в данном наборе политик. Чтобы установить пространственные обязательства, см. тему 'Создание политик с пространственной авторизацией' ниже в этом разделе.

В разделе Conditions, вы можете ограничить политику таким образом, чтобы она подходила только для определённого отрезка времени.

Если вы щёлкните на 'Save policy', политика добавится в набор политик и сохранится в базе данных политик. С этого момента он будет включён во все решения относительно политик, сделанные PDP.

3) Определение политик, ограничивающих доступ пользователей с ролью «Гость» (Guest)

Роль Guest создаётся в securityManager как стандартная. Все шлюзы гостей картированы в эту роль.

Чтобы создать новую политику, выберите созданный набор политик и щёлкните на 'Новый' в нижней части «Политики». В появившемся диалоговом окне введите имя и описание, как вы делали это ранее.

В следующем разделе описано, как установить следующую политику для всех пользователей роли «Гость» (Guest).

Сервис можно загрузить и показать на картах, аналогично слоям 'Bundesländer' (федеральные государства) и 'Kreise' (округа).
Запрос пространственных объектов (GetFeatureInfo) не разрешён.
Использование ограничено периодом 1.1.06 - 1.6.06.
Уведомление об авторском праве должно быть включено во все графические элементы карты.

Чтобы осуществить это, необходимо сконфигурировать следующие значения:

Роли: Выбор роли guest

Ресурсы: место выбора URL сервиса, наряду со слоями 'Bundesländer' и 'Kreise'. Идентификатор слоя показан в квадратных скобках.

'Действия': в примере выше выбраны только 'GetMap' и 'GetCapabilities', тогда как 'GetFeatureInfo' не разрешён.

В разделе 'Conditions – Policy only applies when', установлено уведомление об авторских правах и введён соответствующий текст: '(c) by con terra'.

В разделе Conditions запись изменена, и, дополнительно, использование ограничено во времени. Обратите внимание, что дата используется в форме YYYY-MM-DD (например, 2010-01-10 для 1 января 2010).

Теперь сохраните политику.

4) Определение порядка политик

Пользователь, возможно, имеет более одной роли. Например, в примере выше, если мистер Майер имеет и роль 'Guest' и роль 'internal', вопрос в том, какой политикой обладает мистер Майер для сервиса? Ответ предоставляется порядком политик в наборе. Если принимается решение относительно политики, в списке отдельных политик в наборе осуществляется поиск сверху вниз, пока не будет найдена подходящая политика, разрешающая доступ. Все последующие политики, которые могут предоставить доступ к другим ресурсам, не принимаются во внимание. По этой причине важно удостовериться, что политики с бóльшим значением всегда расположены в верхней части списка.

Чтобы изменить порядок, воспользуйтесь стрелками справа от списка всех политик. Когда в порядок политик вносятся изменения, необходимо сохранить набор политик.

5) Дополнительная информация

Политики можно комбинировать

Другими словами, более сложные политики могут быть выражены только с использованием Администратора securityManager в форме объединения нескольких политик. Например, если нужно установить политики, которые только позволяют, чтобы GetFeatureInfo применялся к слою A, но позволяют, чтобы GetMap и GetCapabilities применялись ко всем слоям, необходимо создать две политики.

Политика 1: Независимо от ресурса, GetMap и GetCapabilities разрешены для роли X.

Политика 2: Для слоя A, GetFeatureInfo разрешён для роли X.

Доступ к незапрещённым ресурсам

В целом, политика должна быть сформирована таким образом, чтобы клиенты не размещали запросы, содержащие неразрешённые ресурсы. В случае WMS это означает, что, поскольку доступ не разрешён для слоя через GetMap, доступ через GetCapabilities тоже не разрешён. Клиенты, которые реагируют динамически на слои, содержавшиеся в Capabilities, который предлагает отобразить их на карте, затем не могут отображать эффективно непригодные слои. Однако, в определенных случаях, может быть желательно для некоторых слоев не появляться в Capabilities, хотя клиенты, которые знают об их существовании, могут получить к ним доступ. Работа всех перехватчиков securityManager, как правило, осуществляется таким образом, что запрос или ответ, требующий доступа к неавторизированным ресурсам, модифицируются, чтобы позволить этим ресурсам быть отфильтрованными. В таком случае клиент получит только сообщение об ошибке, что оно не обладает достаточными правами, авторизированный ресурс не должен оставаться в запросе или ответе.

Иерархические ресурсы (слои)

Администратор предоставляет простой, не иерархичный список слоёв и типов объектов. WMS позволяет придать слоям иерархическую структуру, чтобы обеспечить возможность размещения их по группам. Если Вы используете такой групповой слой с политикой, использование этого слоя автоматически даёт доступ ко всем зависимым слоям, независимо того, были ли эти слои заблокированы или нет.

4.7.5.2.Импорт и экспорт наборов политик

Кнопка Экспорт (Export) в каждом наборе политик может использоваться для экспорта набора в виде файла. Функция импорта доступна для всех наборов политик через узел Unknown (включая те, для которых Администратор не поддерживает диалоговые окна).

4.7.5.3.Неизвестные наборы политик

Администратор securityManager размещает наборы политик в соответствии с известными (и установленными) типами. Для каждого из них программное расширение устанавливает диалоги, чтобы поддерживать политики для сервисов этого типа. Помимо известных типов также могут поддерживаться политики (так называемые неизвестные политики, так как у Администратора нет программного расширения для данных типов). Однако опции поддержки в таком случае ограничены импортом и экспортом и возможностью поддержки содержания через XML view.

Важное примечание: Ошибочно сконфигурированные наборы политик могут оказать негативное влияние на запуск сервиса PDP или даже препятствовать его запуску. Следовательно, изменения в виде XML должны выполняться только опытными Администраторами.

4.7.6.Создание политик с пространственной авторизацией

Использование пространственной авторизации учитывает, что политики доступа будут ограничены пространственными областями. Пространственная авторизация доступна для WMS, WFS, INSPIRE View Service, INSPIRE Feature Download Service, ArcIMS (Image, Feature и ArcMap) и выбранных сервисов ArcGIS. В случае WMS/ArcIMS/ArcGIS Server MapServers, пространственная авторизация, например с запросами GetMap/Map, означает, что недоступная область результирующего изображения отображается белым цветом. Запросы GetFeatureInfo/GetFeature предоставляют информацию только о пространственных объектах в доступной области.

Чтобы ограничить доступ к пространственной области, можно применить обязательство типа 'пространственное ограничение' к политике, для которой должно быть сделано ограничение, с использованием Администратора.

Любой WFS может использоваться как источник для геометрий, которые устанавливают пространственно доступную область (см. системные требования для рекомендуемых версий WFS). В определенной политике ссылки на геометрии WFS сохраняются в виде авторизованных областей. Эти ссылки используются во время авторизации запроса, для запроса WFS для соответствующих геометрий и исправления результирующего изображения в соответствии с геометриями.

4.7.6.1.Последовательность создания политик с пространственной авторизацией

Создание пространственного обязательства

Откройте политику, для которой будет создано пространственное ограничение, и щёлкните в разделе Obligations на Новый (New).

В следующем окне выберите Пространственное обязательство (Spatial Obligation) и щёлкните на Создать новое обязательство (Create New Obligation).

В следующем диалоговом окне Пространственное обязательство (Spatial Obligation), введите имя для обязательства. Имя не должно содержать пробелов и должно ссылаться на пространственную область обязательства.

Выбор геометрии для пространственного обязательства

Теперь вы можете определить, какой WFS должен предоставить геометрии, используемые для пространственной авторизации. Щёлкните на Подключиться (Connect), чтобы протестировать подключение к WFS и обновить список доступных типов пространственных объектов.

Затем определите, какой тип данных должен использоваться для выбранной геометрии для этого обязательства. Если вы хотите использовать другие типы данных для пространственных обязательств в одной политике, вам понадобится создать отдельное пространственное обязательство для каждого типа данных. Обратите внимание, что связанная обработка в процессе пространственной авторизации является относительно дорогой.

Примечание: чтобы упростить выбор геометрий, которые будут использоваться для пространственной авторизации, вы можете выполнить поиск через все области выбранного типа данных и затем выбрать среди расположенных геометрий тех, которые вы хотите использовать в целях авторизации. В разделе Search In, выберите атрибут, для которого должен быть выполнен поиск. В разделе Display Field, вы можете решить, какой признак должен быть показан.

Поиск можно повторять столько раз, сколько требуется.

Также можно использовать символ звёздочки '*', чтобы заменить любую комбинацию символов (например 'A*a' для Аризоны). Функция поиска чувствительна к верхнему и нижнему регистру.

Когда найдены геометрии, выделите те, которые вы хотите использовать в целях пространственной авторизации и щёлкните на 'Использовать выборку для пространственной авторизации'. Выбранный для отображения атрибут и ID выбранной геометрии показаны ниже в списке геометрий, которые будут использоваться для целей пространственной авторизации.

Конфигурирование пространственной авторизации

В области, обозначенной 'Установка пространственного обязательства', можно изменить конкретные параметры, влияющие на пространственную авторизацию.

Устанавливая пространственную операцию (пересечение/внутри), вы решаете, как рассматриваются объекты на краях выбранных геометрий. 'Пересечение' означает, что все геометрии, которые пересекают выбранную геометрию, считаются принадлежащими допустимой области. Если выбрано 'Внутри', геометрия должна быть полностью заключена в пределы выбранных геометрий. Когда обрабатываются растровые данные или данные изображения, это решение не уместно, поскольку в этом случае обработка выбранных типов геометрии основано на пикселах изображения.

В поле 'Система пространственных привязок' показана система пространственных привязок, в которой доступны выбранные геометрии. Если разрешены Трансформации, вы определяете, можно ли трансформировать выбранные геометрии в системе пространственных привязок определённого запроса, в котором применяются выбранные геометрии. Если трансформации разрешены, при определенных обстоятельствах возможно, что неточности в процессе авторизации могут возникнуть на границах выбранных геометрий. Если трансформация не разрешена, возможны только запросы к защищённому сервису в системе пространственных привязок. Запросы в других системах пространственных привязок будут отклонены.

Также возможно определить положительный или отрицательный диапазон допуска вокруг авторизованной геометрии путём установки буфера (в единицах, которые соответствуют системе пространственных привязок авторизованных геометрий).

4.7.6.2.Важная информация для создания пространственных прав

Использование буфера (в контексте области пространственного допуска) является очень важным, если дело касается защиты доступа GET_FEATURE к ArcIMS, поскольку в данном случае метод пространственной операции 'Внутри' не поддерживается. Чтобы симулировать эффект операции ' Внутри ', можно определить отрицательный диапазон допуска после выполнения точного анализа предлагаемых данных, чтобы убедиться, что только эти геометрии пересекаются с (inbound buffered) авторизованной областью, которая полностью заключена в авторизованные геометрии.
Необходимо определить только пространственное обязательство для каждой политики, чтобы не оказать негативного влияния на время обработки процесса авторизации.
Если несколько политик, которые устанавливают пространственные обязательства вовлечены в исследование определённого запроса, пространственные области каждого обязательства объединяются.
Сложные геометрии фильтра замедляют процесс авторизации и процесс построения запроса к сервису. Генерализация геометрий фильтра может оказаться более эффективной, хотя она и может привести к неточности в пограничных областях.

4.7.7.Создание прав для ArcGIS Server

Чтобы создать наборы политик для сервисов ArcGIS Server, выберите ArcGIS Server в дереве навигации.

Чтобы добавить новый ArcGIS Server, щёлкните на символе '+'. Появится диалоговое окно, в котором вы можете выбрать ранее созданный ArcGIS Server на закладке Защищённые сервисы (Protected Services) или ввести URL прямо в поле 'URL of the ArcGIS-Server', сначала выбрав 'Other' в поле Защищённые сервисы (Protected Services).

Щёлкните на кнопке 'Запросить сервисы', чтобы запросить и отобразить доступные сервисы ArcGIS.

Отдельные сервисы ArcGIS Server показаны вместе с кнопками множественного выбора, чтобы вы могли выбрать сервисы, для которых будут созданы policy sets. Щёлкните на кнопке 'Create policy sets', чтобы создать их. Они будут тогда перечислены в узле дерева навигации ArcGIS Server.

Создание политик в пределах этих наборов политик выполняется таким же образом, как и для политик WMS.

4.7.7.1.Интерфейс ArcGIS Server REST

Для доступа к интерфейсу ArcGIS Server REST через securityManager должен использоваться тот же URL, что и для сервисов SOAP. securityManager автоматически перенаправляет все запросы GET к "arcgis/rest/services" вместо "arcgis/services".

Обратите внимание, что поддерживаются только запросы для форматов “f=json” или “f=pjson”. Формат “f=html” вызовет сообщение об ошибке.

4.7.7.2.Определение запросов для ArcGIS Server MapServer

ArcGIS Server MapServer позволяет использовать определяющие запросы, для фильтрации атрибутов или значений атрибутов для конкретных слоев Эффект состоит в том, что MapServer предоставляет только пространственные объекты в соответствии с выражением фильтра. Такие фильтры можно создать с помощью Конструктора запросов ArcMap.

securityManager позволяет добавлять такие определяющие запросы как обязательство для policy, чтобы ограничить доступ только к определённым пространственным объектам. Для создания таких запросов предлагается использовать Конструктор запросов и копировать&вставить их в определение обязательства.

4.7.8.Создание прав для ArcIMS

Чтобы создать права для ArcIMS, выберите узел ArcIMS на закладке Policies.

Щёлкните на символе '+' и либо выберите сервис, который уже был сконфигурирован на закладке Защищённые сервисы (Protected Services), либо выберите опцию закладки 'Другой' и введите ArcIMS URL в соответствующем поле.

Теперь щёлкните на 'Запросить возможности'.

Теперь можно запрашивать и отображать все сервисы ArcIMS. Щёлкните на соответствующей кнопке множественного выбора, чтобы выбрать сервисы, для которых вы хотите создать наборы политик. Если вы щёлкнете на кнопке 'Create policy sets', наборы политик будут созданы и будут доступны в дереве навигации в узле ARcIMS.

Политики создаются так же, как для WMS.

4.7.9.Создание прав для URLs

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

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

Пример базового URL: http://myservice.de

Если не установлены суб-URL, политика не будет применяться к полученным для них URL.

http://myservice.de/index.html
http://myservice.de/de/suburl/document.pdf
http://myservice.de/services/myservice?parameter1=1¶meter2=2

Принимаются во внимание параметры, которые присоединяются к базовому URL с символом '?', что означает, что следующий пример является неотъемлемой частью policy:

http://myservice.de?Parameter1=1&Parameter2=2

Если используются суб-URLS, только они будут приниматься во внимание, что означает, что базовый URL в одиночку больше не является автоматически неотъемлемой частью policy. Могут использоваться символы одной '*' и двух '**' звёздочек ('*' означает любой элемент в пути URL, а '**' означает конец URL).

Пример суб-URL: de**

Во внимание принимается любой суб-URLS, начинающийся с http://myservice.de/de, например:

http://myservice.de/de/index.html
http://myservice.de/de/suburl/document.pdf
http://myservice.de/de?Parameter1=1&Parameter2=2
http://myservice.de/de/service?Parameter1=1&Parameter2=2

Однако следующий URL больше не включается:

http://myservice.de?Parameter1=1&Parameter2=2

Пример суб -URL: */index.html

В этом примере любой элемент может использоваться после базового URL, но на следующем уровне есть ограничение на добавление окончания index.html. Это означает, что следующие URL являются неотъемлемой частью лицензии:

http://myservice.de/de/index.html
http://myservice.de/en/index.html
http://myservice.de/fr/index.html

С другой стороны, следующий URL не принимается во внимание:

http://myservice.de/de/document.pdf

Пример суб -URL: */suburl/**

В этом примере показано, что возможно также использовать to use сцеплённые символы звёздочки. Следующие URL удовлетворяют этому определению:

http://myservice.de/de/suburl/index.html
http://myservice.de/en/suburl/index.html
http://myservice.de/de/suburl/dokument.pdf
http://myservice.de/fr/suburl/suburl2/index.html
http://myservice.de/sonst/suburl/suburl2?Parameter1=1&Parameter2=2

Однако следующие URL не принимается во внимание:

http://myservice.de/suburl/index.html
http://myservice.de/index.html
http://myservice.de?Parameter1=1&Parameter2=2

Введённые URLS перечислены как ресурсы, каждому из них может быть дана либо полная авторизация, либо авторизация только для определённых действий. Доступные действия:e HTTP GET, HTTP POST, HTTP PUT и HTTP DELETE. Обратите внимание, что последние два действия не поддерживаются WSS. securityManager поддерживает дальнейшие механизмы защиты доступа для всех веб-приложений на основе Java, помимо WSS. Политики, содержащие HTTP PUT или HTTP DELETE, будут отклонены WSS, если будет сделан подобный запрос.

Обратите внимание, что в ответном документе для защищённого сервиса ссылки автоматически удаляются, чтобы скрыть их из внешнего представления. Вместо этого используется URL веб-клиента безопасности или enforcement, в зависимости от метода выбранного доступа. Удаляются все абсолютные URL, начинающиеся с URL защищённого сервиса, как и все относящиеся к ним URL, начинающиеся с символа '/'. Ссылки на другой веб-контекст или внешний ресурс игнорируются и переносятся без изменений.

URL удаляется, только если ответный документ защищённого сервиса поддерживает один из следующих типов MIME: text/html, text/xml, text/plain, application/xml,

application/xhtml+xml, application/x-httpd-php, text/javascript, text/vnd.wap.wml или application/x-www-form-urlencoded.

4.7.10.Управление шлюзами

На закладке Gates можно создать постоянные шлюзы для защищённых сервисов. Это означает, что для защищённых сервисов устанавливается особый URL, который связан с определённой учётной записью. Все запросы к этому URL неявно зарегистрированы с этой учётной записью и используются соответствующие права.

Предупреждение: шлюзы, подобные данным, могут использоваться кем угодно! Это можно предотвратить, только держа URL шлюза в секрете, при необходимости, применяя IP фильтры.

4.7.10.1.Просмотр существующего шлюза

Если вы щёлкните на Gates, откроется представление таблицы для всех шлюзов, которые были сконфигурированы.

В таблице показана следующая информация:

Шлюз: имя шлюза. Это имя является частью URL шлюза (Gate URL).
Web Security Service URL: URL Web Security Service, через который доступен сервис.
Истекает: в случае постоянных шлюзов с неограниченным сроком действия это поле остается пустым. Это относится ко всем шлюзам, созданным с использованием Администратора securityManager. Пользователи также могут сами установить шлюз, используя отдельное диалоговое окно приложения Gateway; однако, они будут иметь только ограниченный срок действия. Поскольку такие шлюзы также показаны в этом представлении, в столбце будет содержаться время истечения срока действия шлюза.
IP фильтр: также можно оснастить шлюз IP фильтром. Так как активные шлюзы не требуют дальнейшей аутентификации, каждый запрос автоматически регистрируется с ранее определённым ID пользователя. Установка IP фильтра обеспечивает дополнительную безопасность. В этом поле содержится IP-адрес, место создания этого шлюза. Если в поле появляется сообщение '(IP фильтр дезактивирован)', фильтр не активен.
ID лицензии: для доступа к сервисам, защищенным licenseManager, требуется система ссылок лицензии. В этом случае устанавливается ID этой лицензии. Если используется только securityManager, это поле остаётся пустым.
Последний столбец: здесь можно активировать и дезактивировать шлюз. Если шлюз дезактивирован, можно удалить его. Активные шлюзы нельзя удалить.

4.7.10.2.Детализированный просмотр шлюза

Щёлкните на имени шлюза в первом столбце таблицы, чтобы отобразить его подробное описание.

Отображается URL, связанный с этим шлюзом. Это означает, что данный URL должен использоваться клиентским приложением для вызова защищённого сервиса через этот шлюз.

4.7.10.3.Создание нового шлюза

Можно создать новый шлюз, щёлкнув на кнопке «Создать новый шлюз».

Прежде всего, вводится URL of the Web Security Service, за ним вводится имя шлюза в разделе 'Gateway name'. Автоматически отображается предложенное имя, но оно при желании может быть изменено. Вы можете ограничить доступ к IP-адресам или диапазонам адресов, поставив отметку для опции 'Ограниченный доступ' и введя IP-адрес или диапазон адресов. Диапазон адресов устанавливается с помощью символов '-' и '/', где '-' означает 'от-до' (например, заключительный блок 192.168.2.100-200 допускает все адреса от 100 до 200), '/' означает 'и' (например, заключительный блок 192.168.2.100/200 допускает только 100 и 200 и никаких промежуточных адресов).

Щёлкните на Login, чтобы перейти к странице входа, связанной с создаваемый шлюзом. После успешного входа в систему на закладке Gates будет показан перечень шлюзов.

4.7.11.Работа с securityGateway

Невозможно использовать метод аутентификации WSS для защищённого сервиса с помощью стандартных приложений, так как протокол WSS в настоящее время напрямую поддерживается только небольшим числом приложений, таких как sdi.suite mapClient. Это означает, что, чтобы позволить таким надёжным сервисам использоваться в стандартных приложениях, таких как ESRI ArcMap, необходимо использовать прокси-компонент, который передаёт запросы стандартных сервисов в протокол WSS в соответствии с протоколом надёжного сервиса.

Этот компонент известен как Web Security Client, он доступен в securityManager в форме надёжного шлюза. Он включает пользовательский интерфейс для ввода WSS URLs, имени пользователя и пароля. Web Security Client выполняет процесс входа в WAS. После входа в систему Web Security Client создаёт особый URL для информации этой учётной записи, известный как шлюз. Надёжный сервис клиента по умолчанию может использоваться через определённый для пользователя URL шлюза, как любой другой URL сервиса. Web Security Client выполняет характерную для безопасности коммуникацию с WAS и WSS таким способом, который понятен пользователю.

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

Кроме того, securityGateway может также использоваться для предоставления ранее сконфигурированных шлюзов для надёжных сервисов, т.е. шлюзов с неограниченным сроком действия (постоянные шлюзы). Они могут использоваться для использования в качестве гостя, что не требует от пользователя регистрации. Этот компонент объединен в Администраторе securityManager на закладке Gates (см. раздел : Управление шлюзами).

4.7.11.1.Создание временного доступа на основе учётной записи

Чтобы получить доступ к securityGateway, пользователь вводит адрес

http:///gateway.

В появившемся диалоговом окне пользователь сможет ввести адрес WSS и изменить предложенное имя шлюза. Он также сможет установить, должен ли шлюз быть ограниченной конкретным IP-адресом (IP-адрес вызываемого пользователя – это адрес по умолчанию). Также можно установить диапазоны IP-адресов. securityGateway объединяет имя шлюза в специальном пользовательском разделе URL. Поскольку обладая этим URL, каждый может получить доступ к шлюзу на правах пользователя в системе, следует придумать имя, которое другие пользователи не смогут вычислить.

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

В случае гибридной конфигурации пользовательского управления пользователь должен ввести свое имя, оканчивающееся именем домена (user@).

Если вы щёлкните ещё раз на Login, это приведёт к выполнению временной регистрации, и пользователю будет дан его собственный адрес персонального доступа. Его, например, можно загрузить как WMS URL в любом клиенте WMS.

Примечание: подлинный текст выполняется только один раз в начале работы. Если показан URL временного шлюза, возможно, через нее вошла третья сторона. Соответственно, сообщите это своим пользователям!

Примечание: чтобы защититься от неправильного употребления, шлюз должен быть связан с IP-адресом компьютера, используемым для доступа к securityGateway через браузер.

4.7.11.2.Создание постоянного шлюза на основе учётной записи

Администраторы могут использовать securityGateway, чтобы предварительно сконфигурировать постоянные шлюзы. Доступ к интерфейсу администратора шлюза доступен через URL: http:///gateway/admin/Admin.do.

Управление этим компонентом соответствует управлению шлюзами в Администраторе securityManager. Более подробно см. раздел "Управление шлюзами".

4.7.12.Дополнительные сведения

4.7.12.1.Защита от прямого доступа

Поскольку securityManager обеспечивает безопасность сервисов с помощью Web Security Service, важно убедиться, что заблокирована возможность прямого доступа к сервису, например через интернет. Один из способов сделать это состоит в ограничении доступа через IP-адрес. То, как это сделать, описано в этом разделе с примером Microsoft Internet Information Server and Tomcat Web Server.

4.7.12.1.1.1Internet Information Server

С Microsoft Internet Information Server (IIS) это выполняется следующим образом (частично взято из: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/ Library/IIS/848968f3-baa0-46f9-b1e6-ef81dd09b015.mspx?mfr=true)

Запустите IIS Manager (через управление системой).
Выберите веб-папку, в которой будет доступен защищаемый сервис (например, сервисы 'ArcGIS' for ArcGIS Server). Щёлкните правой кнопкой на папке, чтобы открыть Свойства (Properties).
В окне Свойства (Properties) выберите закладку Безопасность папки (Folder Security) и щёлкните на кнопке Редактировать (Edit, расположенной в разделе 'Ограничения для IP-адресов и имён доменов'.
Выберите опцию по умолчанию 'Отклонить доступ' и введите IP сервера, запускающего WSS в разделе Исключение (Exception). Если оба сервиса установлены на одном компьютере, можно также использовать локальный IP-адрес, 127.0.0.1.
Для подтверждения щёлкните "OK" три раза.

Безопасный сервис теперь может быть доступен только из явно определённого IP-адреса. Доступ заблокирован для всех пользователей.

4.7.12.1.1.2Tomcat Application Server

В Apache Tomcat доступ к конкретному веб-контексту можно ограничить определёнными IP-адресами или именами хоста с помощью так называемых «Клапанов» (Valves). Чтобы сделать это, откройте файл, содержащий элемент контекста веб-приложения, которое будет защищено. Элемент «клапан» тогда добавляется к элементу контекста веб-приложения, что приведёт к двум разным способам выполнения: один из них допускает спецификации ограничений для определённых хостов на основе имён хостов, другой – для использования IP-адресов.

Пример Контекста с ограниченным доступом:

...

allow="*.mycompany.com,www.yourcompany.com"/>

deny="192.168.1.*"/>

...

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

(Источник: http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html#Remote%20Address%20Filter)