Содержание


Передача функций защиты Web-сервисов на платформе WebSphere устройствам IBM WebSphere DataPower SOA Appliance

Часть 5. Настройка прокси Web-сервисов на взаимодействие с WCF .NET-клиентом

Comments

Серия контента:

Этот контент является частью # из серии # статей: Передача функций защиты Web-сервисов на платформе WebSphere устройствам IBM WebSphere DataPower SOA Appliance

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Передача функций защиты Web-сервисов на платформе WebSphere устройствам IBM WebSphere DataPower SOA Appliance

Следите за выходом новых статей этой серии.

В данной статье рассматривается взаимодействие WCF-DataPower с использованием маркеров Kerberos. Это пятая часть серии статей "Передача функций защиты Web-сервисов на платформе WebSphere устройствам IBM WebSphere DataPower SOA Appliance". Авторы благодарят Шиу Пунь (Shiu F. Poon) за рецензирование статьи и ценные замечания.

Базовый сценарий

В инфраструктуре WCF .NET 3.5 необходимо настроить клиента Web-сервисов на применение аутентификации Windows и защиты сообщений, использующей маркеры Kerberos, а также на взаимодействие с DataPower, которое выступает в роли прокси для Web-сервисов. На рисунке 1 изображена схема базового сценария.

Рисунок 1. Базовый сценарий
Рисунок 1. Базовый сценарий
Рисунок 1. Базовый сценарий

Требования

  • WebSphere DataPower 3.8.0 или более новой версии.
  • Windows 2003 Server с Active Directory.
  • Компьютер с клиентом Windows, являющийся частью домена Active Directory.
  • Инфраструктура Microsoft .NET 3.5.
  • Visual Studio 2008 (не обязательна, но облегчает работу).

Действия по настройке

Давайте подробно рассмотрим три основные области настройки:

  1. Создание принципалов и keytab-файлов в Active Directory.
  2. Настройка WCF-клиента.
  3. Настройка устройства DataPower.

Создание принципалов и keytab-файлов в Active Directory.

Настройка Active Directory и IIS

Если Active Directory и IIS у вас уже настроены и работают, пропустите данный раздел и переходите к разделу "Настройка WCF-клиента".

  • Установите Active Directory (контроллер доменов)
    Ссылки на дополнительную информацию по [InstallActiveDirectory] или [InstallActiveDirectoryDNS] для установки и настройки контроллера доменов приведены в разделе "Ресурсы".
  • Установите IIS (сервер приложений)
    Ссылки на дополнительную информацию по [InstallIIS] приведены в разделе "Ресурсы". Она поможет установить IIS. Также обратите внимание на тему "Не запускается сервис, размещенный в IIS" в разделе "Устранение неисправностей".

Создание SPN для представления в Active Directory прокси-сервиса устройства WebSphere DataPower

Для того чтобы клиент получил билет Kerberos для генерирования маркера Kerberos, необходимо создать целевое SPN (Service Principal Name – имя принципала сервиса). Вам потребуется доступ к консоли Active Directory Users and Computers, а также к программе setspn.exe (для Windows 2003 ее можно загрузить с сайта Microsoft или найти на компакт-диске Windows 2003 Tools).

  1. Создайте псевдо-пользователя AD, который будет использоваться для отображения SPN. Для данного примера создайте AD-пользователя wcfservice.
  2. Создайте SPN, отображаемое на пользователя wcfservice, созданного ранее:
    setspn –a dpbox/wcfservice wcfservice,
    где dpbox – любой произвольный префикс, а wcfservice – имя, использующееся для представления устройства WebSphere DataPower.
    Примечание. SPN – это строка. Можно выбрать любое имя или формат. Например, в качестве SPN можно указать HOST/hostname:port или HOST/hosname и т.д.
  3. Проверьте корректность регистрации SPN:
    setspn -l wcfservice
    Список должен содержать SPN.

Генерирование Keytab-файла Kerberos для SPN

Для работы Kerberos необходимо отобразить SPN на пользователя и создать keytab-файл Kerberos, который будет использоваться с WebSphere DataPower. Для этого мы будем использовать программу ktpass. Ссылка на информацию [InstallKTPass] по ее установке находится в разделе "Ресурсы".

В нашем примере для пользователя wcfservice и области (realm) WPS.CSUPPORT.COM команда ktpass должна выглядеть следующим образом:

ktpass -out c:\temp\wcfservice.keytab -princ dpbox/wcfservice@WPS.CSUPPORT.COM -mapUser wcfservice -mapOp set -pass <passwordforuser> -crypto RC4-HMAC-NT [–ptype KRB5_NT_PRINCIPAL] [ –kvno <kvno>]

ПРИМЕЧАНИЕ.

  1. Для корректной работы важно присвоить параметру -crypto значение RC4-HMAC-NT (DES является более слабым алгоритмом и может не работать совместно с WebSphere DataPower).
  2. Ключ –ptype KRB5_NT_PRINCIPAL не является обязательным.
  3. Ключ –kvno <kvno> необходим, если нужно указать конкретное значение номера версии ключа, например -kvno 1. Очень часто для сгенерированного keytab-файла возникает ошибка kvno mismatch error (ошибка несоответствия kvno). В разделе "Устранение неисправностей" приведена информация о подобных ошибках и о том, какие сообщения могут появиться в WebSphere DataPower при несоответствии kvno.

Необходимо скопировать keytab-файл c:\temp\wcfservice.keytab в DataPower (см. раздел "Настройка DataPower Device").

Настройка WCF-клиента

Загрузка примеров WCF

В данной статье мы продемонстрируем взаимодействие примеров WCF и WebSphere DataPower, настроенных на применение windows-аутентификации и защиты сообщений с использованием маркеров Kerberos. Прежде всего необходимы работающие WCF-клиент и WCF-сервис (пока без WebSphere DataPower). Если WCF-клиент уже настроен, можете пропустить этот раздел и перейти к разделу "Изменение файла app.config".

  1. Установите примеры WCF [WCFSamples]. Убедитесь в отсутствии предупреждений и ошибок.
    Примечание. Должны быть установлены Active Directory и IIS, как описано в разделе "Настройка Active Directory и IIS".
  2. Для компоновки решения в Visual Studio 2008 мы будем использовать проект WCF_SAMPLES\WCF\Basic\Binding\WS\Http.
  3. Убедитесь, что сервис работает, перейдя по адресу http://localhost/servicemodelsamples/service.svc?wsdl.

Изменение файла app.config

  1. Запретите использование маркеров SPNEGO по умолчанию.

После запуска WCF-клиента и сервиса можно продолжить настройку и изменить файл app.config, чтобы запретить использование маркеров SPNEGO по умолчанию и разрешить маркеры Kerberos (при взаимодействии с DataPower WCF-клиент должен использовать маркеры Kerberos для подписи и шифрования запросов). Это можно сделать, установив параметр negotiateServiceCredential="false" в файле app.config.

Листинг 1. Запрет использования маркеров SPNEGO по умолчанию
<security mode="Message">
    <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
    <message clientCredentialType="Windows" negotiateServiceCredential="false"
                            algorithmSuite="Basic128" establishSecurityContext="false" />
</security>
Листинг 2. Изменение algorithmSuite на Basic128
<security mode="Message">
    <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
    <message clientCredentialType="Windows" negotiateServiceCredential="false"
                            algorithmSuite="Basic128" establishSecurityContext="false" />
</security>

На предыдущем шаге мы отключили negotiateServiceCredential. Нужно также изменить algorithmSuite на Basic128 вместо используемого по умолчанию Basic256. Это необходимо, поскольку в Active directory билеты Kerberos генерируются со 128-разрядными ключами. Более подробная информация приведена в разделе "Устранение неисправностей".

Защищенный обмен можно включить или отключить путем изменения значения параметра establishSecurityContext. Значение false отключает защищенный обмен, а значение true включает.

Листинг 3. Отключение/включение защищенного обмена
<security mode="Message">
    <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
    <message clientCredentialType="Windows" negotiateServiceCredential="false"
                            algorithmSuite="Basic128" establishSecurityContext="false" />
</security>

Если защищенный обмен включен, WCF-клиент отправляет первоначальный запрос RequestSecurityToken вместе с маркерами Kerberos. После приема этого запроса WebSphere DataPower проверит маркеры Kerberos, сгенерирует SCT (Security Context Token – маркер контекста защиты) и отправит его клиенту. Все последующие транзакции между WebSphere DataPower и клиентом будут подписаны и зашифрованы с использованием этого SCT.

Обратите внимание, что если вы включаете защищенный обмен в WCF-клиенте, необходимо настроить DataPower на обработку первоначальных запросов защищенного обмена (см. раздел "Обработка защищенного обмена").

Затем включите элемент identity с именем принципала сервиса, созданным ранее (в обеих конфигурациях - и клиента, и сервиса).

Листинг 4. Отключение/включение защищенного обмена
<identity>
    <servicePrincipalName value="dpbox/wcfservice@WPS.CSUPPORT.COM"/>        
</identity>

Заметьте, что здесь должен быть указан тот же принципал сервиса, который был указан в команде ktpass, рассмотренной в разделе "Генерирование Keytab-файла Kerberos для SPN".

Затем настройте обработчик WebSphere DataPower Http Front Side Handler на обработку всех входящих запросов от WCF-клиента. Измените файл app.config так, чтобы он указывал на порт и имя хоста WebSphere DataPower. Также проверьте правильность URI.

Кроме того, до изменения конечной точки можно попробовать перезапустить WCF-клиент и сервис (пока без WebSphere DataPower), чтобы убедиться в корректной работе WCF-клиента и сервиса, использующих маркеры Kerberos вместо маркеров Spnego по умолчанию.

Измененный файл app.config должен выглядеть примерно так, как показано в листинге 5.

Листинг 5. Файл App.config WCF-клиента
<?xml version="1.0 encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <ws2007HttpBinding>
                <binding name=WS2007HttpBinding_ICalculator" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00"
					sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" 
                                hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" 
                                maxArrayLength="16384"
                        maxBytesPerRead="4096" maxTableCharCount="16384"/>
                    <reliableSession ordered="true" inactivityTimeout="00:10:00" 
                                enabled="false"/>
                    <security mode="Message">
                        <transport clientCredentialType="Windows" 
                                proxyCredentialType="None" realm=""/>
                        <message clientCredentialType="Windows" 
                                negotiateServiceCredential="false" 
                                    algorithmSuite="Basic128" 
                                    establishSecurityContext="true"
                    </security>
               </binding>
           </ws2007HttpBinding>
        </bindings>
        <client>
        <!-- DNS-имя datapower конечной точки должно быть настроено
		 внутри файла local hosts -->
            <endpoint address="http://datapower:8009/WS2007HttpKrbSC/service.svc"
                binding="ws2007HttpBinding" 
				bindingConfiguration="WS2007HttpBinding_ICalculator"
                contract="ICalculator" name="WS2007HttpBinding_ICalculator_DP">
                <identity>
                <servicePrincipalName value="dpbox/wcfservice@WPS.CSUPPORT.COM"/>
                </identity>
            </endpoint>
        </client>
    </system.serviceModel>
</configuration>

Настройка WebSphere DataPower

Настройка WS-Proxy

Прокси Web-сервисов должен быть настроен так, чтобы он гарантировал использование необходимых для wsHttpBinding/ws2007HttpBinding политик и требовал подписывания и шифрования транзакций с применением маркеров Kerberos. Необходимо выполнить следующие действия:

  1. Добавьте wsdl сервиса.
  2. Прикрепите необходимую политику WS-Security.
  3. Прикрепите необходимый набор параметров политики (Policy Parameter Set).
  4. Настройте вкладку Proxy Settings на дешифрование.

В данной статье предполагается, что вы знакомы с основными действиями по настройке прокси Web-сервисов: добавление WSDL, настройка обработчика HTTP Front Side Handler, задание правильного URI и настройка сервиса на сервере (backend service). Отметим, что поставляемая с данной статьей конфигурация WebSphere DataPower включает все эти настройки для нескольких примеров WS-Proxies.

1. Добавление wsdl сервиса

Wsdl-файл для примера сервиса калькулятора (для w2007HttpBinding) можно найти по адресу http://localhost/servicemodelsamples/service.svc?wsdl .NET-сервиса, в котором вы установили примеры WCF. Если вы планируете импортировать этот wsdl-файл в WebSphere DataPower, возможно, понадобится скопировать в DataPower дополнительные файлы схем и изменить URI импорта WSDL:

<wsdl:import namespace = "http://Microsoft.ServiceModel.Samples" location =
        "local:///CalculatorServiceDefinition.wsdl"/>

Также не забудьте удалить элементы policy из WSDL-файла. В следующих разделах мы добавим предоставляемые WebSphere DataPower шаблонные политики как элементы reference.

Рисунок 2. Добавление wsdl сервиса
Рисунок 2. Добавление wsdl сервиса
Рисунок 2. Добавление wsdl сервиса

В данном примере в качестве сервера выступает сетевой XML-экран-заглушка (loopback XML firewall), извлекающий статический файл AddResponse.xml. Обычно впоследствии он заменяется Web-сервером.

Локальный URI должен совпадать с указанным в конечной точке в файле app.config клиента.

2. Прикрепите необходимую политику WS-Security Policy

С WebSphere DataPower поставляется несколько файлов шаблонов в каталоге store://policies/templates/dotnet. Необходимо выбрать правильный файл и правильный wsu:id в нем и добавить его в wsdl. Давайте рассмотрим, как выбрать "правильные" файл шаблона и wsu:id.

В данном примере WCF-клиент настроен на использование ws2007HttpBinding с маркерами Kerberos, а защищенный обмен запрещен. Также обратите внимание на параметр AlgorithmSuite в файле app.config клиента. Он установлен в Basic128. Следовательно, при выборе файла шаблона в каталоге store://policies/templates/dotnet мы должны учитывать следующие параметры:

Template file: wsp-sp-1-2-ws2007HttpBinding.xml
Binding: symmetric
Token: Kerberos
AlgorithmSuite: Basic128 
Secure Conversation: No

Поэтому элемент PolicyReference (ссылка на политику) должен выглядеть следующим образом:

<wsp:PolicyReference URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#symmetric-kerberos-basic128"/>.

Также следует добавить политики входа и выхода, как показано в листинге 6.

Листинг 6. Добавление PolicyReference в wsdl-файл сервиса
<wsdl:import namespace = "http://Microsoft.ServiceModel.Samples" location =
"local:///CalculatorServiceDefinition.wsdl"/>
<wsdl:types/>
<wsdl:binding name = "WS2007HttpBinding_ICalculator" type = "i0:ICalculator">
    <wsp:PolicyReference
URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml
                                            #symmetric-kerberos-basic128"/>
    <soap12:binding transport = "http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="Add">
        <soap12:operation soapAction =
"http://Microsoft.ServiceModel.Samples/ICalculator/Add" style = "document"/>
        <wsdl:input>
            <wsp:PolicyReference
URI="store:///policis/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#input"/>
            <soap12:bosy use = "literal"/>
        </wsdl:input>
        <wsdl:output>
            <wsp:PolicyReference
URI="store:///policies/templates/donet/wsp-sp-1-2/ws2007HttpBinding.xml#output"/>
            <soap:12body use = "literal"/>
        </wsdl:output>
    </wsdl:operation>       
</wsdl:binding>
<wsdl:service name = "CalculatorService">
    <wsdl:port name = "WS2007HttpBinding_ICalculator" binding =
"tns:WS2007HttpBinding_ICalculator">
        <soap12:address location = "http://wcfnet/ServiceModelSamples/service.svc"/>
        <wsa10:EndpointReference>
            <wsa10:Address>http://wcfnet/ServiceModuleSamples/service.svc</wsa10:Address>
            <Identity xmlns =
"http://schemas.xmlsoap.org/ws/2006/02/addressingidentitiy">
                <Spn>HOST/wcfnet</Spn>
            </Identity>
        </wsa10:EndpointReference>
    </wsdl:port>
</wsdl:service>

Также необходимо разрешить WSDL-Embedded Policy References на вкладке policy, как показано на рисунке 3.

Рисунок 3. Разрешение WSDL-Embedded Policy References
Рисунок 3. Разрешение WSDL-Embedded Policy References
Рисунок 3. Разрешение WSDL-Embedded Policy References

Отметим, что вместо изменения WSDL-файла можно сохранить исходный WSDL-файл сервиса и подключить PolicyReference на вкладке policy из интерфейса webgui, как показано на рисунке 4. Но здесь есть одно ограничение. Интерфейс webgui нельзя использовать для прикрепления политики к Message Policy Subject. Поэтому в данном примере в дополнение к тому, что изображено на рисунке 4, все равно необходимо добавить ссылки на политику входа и выхода в WSDL-файле сервиса:

<wsdl:input>
    <wsp:PolicyReference
	 URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml
                           #input"/>   
    <soap12:body use = "literal"/>
</wsdl:input>
<wsdl:output>
    <wsp:PolicyReference
	 URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml
                            #output"/>  
    <soap12:body use = "literal"/>
</wsdl:output>
Рисунок 4. Прикрепление политики к WSDL сервиса при помощи WebGUI
Рисунок 4. Прикрепление политики к WSDL сервиса при помощи WebGUI
Рисунок 4. Прикрепление политики к WSDL сервиса при помощи WebGUI

3. Прикрепление необходимого набор параметров политики

На вкладке Policy Parameter Set настройте параметры для маркера Kerberos так, как показано на рисунке 5.

Kerberos Server Principal – это имя SPN, созданное ранее в разделе "Генерирование Keytab-файла Kerberos для SPN", например dpbox/wcfservice@WPS.CSUPPORT.COM.

Kerberos Client Principal – имя принципала того, кто подписал входящий запрос. В нашем примере это wcfclient@WPS.CSUPPORT.COM. Это имя принципала, назначенное пользователю, который вошел в систему на машине WCF-клиента и активизировал клиентское приложение. Обратите внимание, что Kerberos Client Principal на самом деле не используется до тех пор, пока не будет разрешен параметр Enforce Kerberos Client Principal.

Kerberos Keytab – это keytab-файл принципала сервера (server-principal). Если его еще нет, создайте объект Kerberos keytab object, загрузив keytab-файл, созданный при помощи команды ktpass (см. раздел "Создание принципалов и keytab-файлов в Active Directory").

Interoperable with Microsoft - необходимо добавлять этот параметр всегда, когда нужно обеспечить взаимодействие WebSphere DataPower с любыми из связываний, поддерживаемых Microsoft.

Отметим, что домен политик (policy domain) должен соответствовать указанному в файле шаблона. В данном примере в файле шаблона store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml пространство имен политики безопасности указано как xmlns:sp = http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702. Поэтому нужно добавлять параметры политики к этому пространству имен.

Рисунок 5. Добавление Policy Parameter Set к WSDL-файлу сервиса
Рисунок 5. Добавление Policy Parameter Set к WSDL-файлу сервиса
Рисунок 5. Добавление Policy Parameter Set к WSDL-файлу сервиса

4. Настройка вкладки Proxy Settings на дешифрование

При использовании wsHttpBinding/ws2007HttpBinding сообщения подписываются и шифруются при помощи маркеров Kerberos. Для дешифрования входящего сообщения необходимо указать удостоверения дешифрования (decryption credentials) на вкладке proxy settings прокси Web-сервисов, как показано на рисунке 6. Имя Server Principal должно таким же, как указанное в команде ktpass, а keytab-файлом должен быть файл, созданный командой ktpass, рассмотренной в разделе "Генерирование keytab-файла Kerberos для SPN". Имя Client Principal в нашем случае не обязательно.

Рисунок 6. Удостоверения дешифрования на вкладке Proxy Settings
Рисунок 6. Удостоверения дешифрования на вкладке Proxy Settings
Рисунок 6. Удостоверения дешифрования на вкладке Proxy Settings

Защищенный обмен

Если WCF-клиент настроен на защищенный обмен (establishSecurityContext="true"), WebSphere DataPower следует настроить соответствующим образом. В дополнение к рассмотренным в предыдущих разделах необходимо выполнить следующие действия по настройке:

  1. Добавьте WSDL-файл STS для обработки первоначальных запросов защищенного обмена.
  2. Прикрепите необходимую политику WS-Security Policy к WSDL STS.
  3. Прикрепите необходимый набор Policy Parameter Set к WSDL STS.
  4. Отключите проверку корректности схемы.

1. Добавление WSDL-файла STS для обработки первоначальных запросов защищенного обмена

Для обработки первоначальных запросов защищенного обмена (RequestSecurityToken) необходимо добавить WSDL-файл STS к прокси Web-сервисов (см. рисунок 7). Обратите внимание на обработчик локальной конечной точки и на URI. Они должны соответствовать указанным в WSDL-файле сервиса.

Рисунок 7. Добавление WSDL STS для обработки защищенного обмена
Рисунок 7. Добавление WSDL  STS для обработки защищенного обмена
Рисунок 7. Добавление WSDL STS для обработки защищенного обмена

2. Прикрепление необходимой политики WS-Security Policy к WSDL STS

К WSDL STS следует также добавить файл шаблона с правильным wsu:id. Отметим, что поскольку защищенный обмен разрешен, элемент PolicyReference должен иметь значение <wsp:PolicyReference URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml #symmetric-kerberos-sc-basic128"/> как для WSDL STS, так и для WSDL сервиса. В листинге 7 приведен пример WSDL STS.

Листинг 7. Добавление PolicyReference к WSDL STS
<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions targetNamespace="http://schemas.xmlsoap.org/ws/2005/02/trust"
    xmlns:tns="http://schemas.xmlsoap.org/ws/2005/02/trust"
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:echo="http://com/ibm/was/wassample/sei/echo/"
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
	oasis-200401-wss-security-utility-1.0.xsd">

<wsdl:types>
    <xs:schema targetNamespace="http://schemas.xmlsoap.org/ws/2005/02/trust"
blockDefault="#all" elementFormDefault="qualified">
        <xs:element name="RequestSecurityToken">
            <xs:complexType>
                <xs:sequence>
                    <xs:any namespace="##any" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:anyAttribute namespace="##any" processContents="lax"/>
            </xs:complexType>                
        </xs:element>
        <xs:element name="RequestSecurityTokenResponse">
            <xs:complexType>      
                <xs:sequence> 
                    <xs:any namespace="##any"/>        
                </xs:sequence> 
            </xs:complexType>
        </xs:element>
    </xs:schema>
</wsdl:types>

<!--Определения частей сообщения для запроса/ответа начальной загрузки-->
<wsdl:message name ="RequestSecurityToken">
    <wsdl:part name="Body" element="tns:RequestSecurityToken"/>

<!--Здесь нужно включить определение конечной точки/операции для
 прикрепления политики для сообщений начальной загрузки-->

<wsdl:portType name="Test">
    <wsdl:operation name="RequestSecurityToken">
        <wsp:PolicyReference
URI="store:///policies/templates/dotnet/
wsp-sp-1-2-ws2007HttpBinding.xml#symmetric-kerberos-sc-basic128"/>
        <wsdl:input message="tns:RequestSecurityToken"/>
        <wsdl:output message="tns:RequestSecurityTokenResponse"/>
    </wsdl:operation>
<wsdl:portType>

<wsdl:binding name="T1Binding" type="tns:Test">
    <soap12:binding style="document"
transport="http://schemas/xmlsoap.org/soap/http"/>
    <wsdl:operation name="RequestSecurityToken">
<!-- 
    <soap12:operation
soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT"/>
    <soap12:operation
soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel"/>
-->
<!-- прикрепить связывание приложения к wsdl:input и wsdl:output, чтобы
 инфраструктура политики смогла понять, как работать с остальным трафиком,
  отличным от сгенерированного
-->
    <wsdl:input>  
        <wsp:PolicyReference
URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#input"/>
        <soap12:body use="literal"/>
    </wsdl:input>   
    <wsdl:output>
        <wsp:PolicyReference
URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#output"/>
         <soap12:body use="literal"/>
    </wsdl:output>
</wsdl:operation>
</wsdl:binding>

<wsdl:service name="Test">
    <wsdl:port name="BootstrapPort" binding="tns:T1Binding">
        <soap12:address location="https://www.soaphub.org/RequestSecurityToken"/>
    </wsdl:port>
</wsdl:service>
</wsdl:definitions>

3. Прикрепление необходимого набора параметров Policy Parameter Set к WSDL STS

Прикрепите такой же параметр политики, как описанный в разделе "Прикрепление необходимого набора параметров Policy Parameter Set к конечной точке WSDL STS" (см. рисунок 8).

Рисунок 8. Прикрепление набора параметров Policy Parameter Set к STS WSDL
Рисунок 8. Прикрепление набора параметров Policy Parameter Set к STSWSDL
Рисунок 8. Прикрепление набора параметров Policy Parameter Set к STSWSDL

4. Отключение проверки схемы

Ответ на RequestSecurityToken подписывается и шифруется. Проверку корректности схемы необходимо запретить в WSDL STS как для запроса, так и для ответа; также ее следует запретить для ответов в WSDL-файле сервиса, как показано на рисунке 9.

Рисунок 9. Отключение проверки схемы
Рисунок 9. Отключение проверки схемы
Рисунок 9. Отключение проверки схемы

Различия между wsHttpBinding и ws2007HttpBinding

Наверное, вы заметили, что в наших примерах используется ws2007HttpBinding. А что если использовать wsHttpBinding? Ниже перечислены различия:

  1. При настройке WCF-клиента используйте <wsHttpBinding> (вместо ws2007HttpBinding) в app.config. Пример приведен в листинге 8.
Листинг 8. Пример app.config для wsHttpBinding
<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_ICalculator" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" 
					sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" 
                                hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" 
                                maxArrayLength="16384"
                        maxBytesPerRead="4096" maxTableCharCount="16384"/>
                    <reliableSession ordered="true" inactivityTimeout="00:10:00" 
                                enabled="false"/>
                    <security mode="Message">
                        <transport clientCredentialType="Windows" 
                                proxyCredentialType="None" realm=""/>
                        <message clientCredentialType="Windows" 
                                negotiateServiceCredential="false" 
                                    algorithmSuite="Basic128" 
                                    establishSecurityContext="true"
                    </security>
               </binding>
           </wsHttpBinding>
        </bindings>
        <client>
            <!-- DNS-имя datapower конечной точки должно быть настроено
			 внутри файла local hosts-->
                <endpoint address="http://datapower:8007/WSHttpKrb/service.svc"
                    binding="wsHttpBinding"
					 bindingConfiguration="WSHttpBinding_ICalculator"
                    contract="ICalculator" name="WSHttpBinding_ICalculator_DP">
                    <identity>
                        <servicePrincipalName
                            value="dpbox/wcfservice@WPS.CSUPPORT.COM"/>
                    </identity>
                </endpoint>
        </client>
    </system.serviceModel>
</configuration>
  1. Во время настройки WSDL-файла DataPower и подключения политики WS Security Policy выберите соответствующий wsHttpBinding файл шаблона при добавлении PolicyReference. Например, <wsp:PolicyReference URI="store:///policies/templates/dotnet/wsp-sp-1-1-wsHttpBinding.xml#symmetric-kerberos-sc-basic128"/>.
  2. Во время настройки набора Policy Parameter Set для DataPower обязательно назначайте все параметры политики корректному домену политики, соответствующему wsHttpBinding. Например, http://schemas.xmlsoap.org/ws/2005/07/securitypolicy.

К этому моменту мы полностью завершили необходимую настройку. Запустите клиент и понаблюдайте за процессом передачи ответа от WebSphere DataPower.

Устранение неисправностей

IIS hosted Service fails (не запускается сервис, размещенный в IIS)

По умолчанию после установки IIS ASP.NET использует версию 1.0. Необходимо зарегистрировать версию 2.0, используя команду aspnet_regiis.exe -i в
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727.

Если этого не сделать, мы не сможем развернуть в IIS сервис примера (описанный в данной статье).

Cannot parse file for Kerberos Keytab (нельзя выполнить синтаксический анализ keytab-файла Kerberos) или Bad checksum on Kerberos AP-REQ message (неправильная контрольная сумма сообщения AP-REQ Kerberos)

Если данная ошибка появляется в DataPower, скорее всего, вы столкнулись с известной ошибкой несоответствия kvno или несоответствия алгоритмов. К сожалению, сообщения об ошибках и зарегистрированные сообщения в WebSphere DataPower не могут указать на причины несоответствия или даже на то, что это действительно ошибка несоответствия (возможно, поврежден keytab-файл).

Ошибка несоответствия алгоритма может возникнуть, если алгоритм шифрования, используемый в маркере AP-REQ, отличается от указанного в keytab-файле. Вероятно, вы увидите сообщение Bad checksum on Kerberos AP-REQ message. Используйте RC4-HMAC-NT в команде ktpass.

Ошибка несоответствия kvno может возникнуть, если kvno в keytab-файле, используемом DataPower, отличается от kvno, используемом KDC. Номер версии ключа, используемого KDC, можно определить при помощи команды [ldifde] в KDC:

ldifde -f c:\spn.txt -d "DC=<yourdomain>,DC=com" -l *,msDS-KeyVersionNumber -r 
                "(serviceprincipalname=<yourspn>*)" -p subtree

Для примера, рассмотренного в данной статье, можно использовать команду:

ldifde -f c:\spn.txt -d "DC=wps,DC=csupport,DC=com" -l *,msDS-K
eyVersionNumber -r "(serviceprincipalname=dpbox/wcfservice*)" -p subtree

Теперь проверьте msDS-KeyVersionNumber. Это kvno, используемый KDC для данного конкретного SPN.

С другой стороны, kvno, используемый в keytab-файле, можно определить на linux-машине при помощи команды kt_util:

/usr/kerberos/sbin/ktutil:
read_kt <keytabfileName>

Если они не совпадают, повторно сгенерируйте keytab-файл, используя команду ktpass со значением параметра –kvno, используемым KDC.

Если ошибка не исчезает, возможно, имеется несколько модификаций SPN или его пользователя. Удалите spn (setspn –d), пользователя и начните с нуля: создайте пользователя, создайте SPN, создайте keytab-файл, используя команду ktpass, и скопируйте его в DataPower. Проверьте правильность имен принципалов (соответствие регистров букв), кроме того, имя области (realm) должно указываться прописными буквами.

algorithmSuite=Basic256 does not work (algorithmSuite=Basic256 не работает)

После отключения NegotiateServiceCrendential не работает algorithmSuite=Basic256. Причина (согласно информации службы поддержки Microsoft) заключается в следующем:

  1. Билеты Kerberos генерируются со 128-разрядным ключом по умолчанию. Следовательно, они не будут работать с 256-разрядными алгоритмами из набора Basic256. Выходом из этой ситуации является использование Basic128, применяющегося в WCF по умолчанию при прямой аутентификации Kerberos, т.е. когда параметру negotiateServiceCredentials присвоено значение false.
  2. Аналогичная настройка работает при negotiateServiceCredentails=true. Это происходит потому, что при negotiateServiceCredentails=true мы используем SspiNegotiation (многократно) вместо Kerberos direct (однократно). При SspiNegotiation WCF генерирует подходящий по размеру криптографический ключ после согласования деталей защиты и проверки совместимости участников обмена. Но режим Kerberos такой свободой не обладает. Клиент генерирует 128-разрядный Kerberos-ключ, который не работает на стороне сервиса.

Просмотр отладочной информации в WebSphere DataPower

После включения в DataPower режима просмотра отладочной информации (Probe) можно просмотреть сообщения запросов и ответов в удобном для отладки виде.

Если настроен защищенный обмен, вы увидите три запроса, показанные на приведенном ниже рисунке.

  1. Запрос маркера Security Context Token.
  2. Запрос реального сервиса для добавления двух чисел.
  3. Запрос отмены маркера Security Context Token.
Рисунок 10. Просмотр отладочной информации
Рисунок 10. Просмотр отладочной информации
Рисунок 10. Просмотр отладочной информации

Что нового в версии 3.8.0

В данном разделе перечислены новые возможности версии 3.8.0.

Параметр политики Disable SSL Cipher Suite Check (отключение проверки набора шифров SSL)

Этот параметр политики позволяет запретить проверку шифров SSL в прокси Web-сервисов. Это удобно при настроенном внешнем https-обработчике и возникновении таких ошибок прокси Web-сервисов, как Execution of 'store:///dp/transport-check.xsl' aborted: Invalid SSL bulk encryption key length.

После включения параметра Disable SSL Cipher Suite check (см. рисунок 11) прокси Web-сервисов не будет выполнять проверку набора шифров SSL, который уже согласован внешним https-обработчиком.

Рисунок 11. Параметр политики Disable SSL Cipher Suite Check (отключение проверки набора шифров SSL)
Рисунок 11. Параметр политики Disable SSL Cipher Suite Check (отключение проверки набора шифров SSL)
Рисунок 11. Параметр политики Disable SSL Cipher Suite Check (отключение проверки набора шифров SSL)

Заметьте, что ошибки Invalid SSL bulk encryption key length (неверная длина ключа шифрования SSL) можно избежать путем настройки криптографического профиля внешнего https-обработчика на использование алгоритма, поддерживаемого прокси Web-сервисов. Но это будет означать, что вы отказываете множеству клиентов, не поддерживающих этот алгоритм SSL-синхронизации.

Параметр политики Enforce Kerberos Client Principal

Параметр Kerberos client principal не используется до тех пор, пока не будет включен параметр Enforce Kerberos Client Principal. После его включения (см. рисунок 12) действия по проверке, сгенерированные политикой безопасности, сравнивают значение параметра Kerberos client principal со значением подписчика сообщения во входящем запросе. Если они не соответствуют друг другу, запрос отклоняется.

Рисунок 12. Параметр политики Enforce Kerberos Client Principal
Рисунок 12. Параметр политики Enforce Kerberos Client Principal
Рисунок 12. Параметр политики Enforce Kerberos Client Principal

Поддерживаемые маркеры и WCF-связывания

Мы поддерживаем приведенные ниже связывания, а поставляемые со статьей файлы примеров содержат прокси Web-сервисов, настроенные на каждое из этих связываний, как показано на рисунке 13.

  • BasicHttpBinding – разрешен SSL и SSL с запросом сертификата клиента.
  • wsHttpBinding/ ws2007HttpBinding – маркеры Kerberos и X509 с защищенным обменом и без него.
  • wsFederationBinding и ws2007Federation – маркеры SAML1 и SAML2.
Рисунок 13. Прокси Web-сервисов для каждого поддерживаемого связывания
Рисунок 13. Прокси Web-сервисов для каждого поддерживаемого связывания
Рисунок 13. Прокси Web-сервисов для каждого поддерживаемого связывания

В каталог store://policies/templates/dotnet добавлены несколько файлов шаблонов, как показано на рисунке 14.

Рисунок 14. Файлы шаблонов
Рисунок 14. Файлы шаблонов
Рисунок 14. Файлы шаблонов

Каждый из этих файлов шаблонов содержит несколько wsu:ids. В разделе "Ресурсы" приведены ссылки на дополнительную информацию о том, как подключить необходимую политику WS-Security Policy при выборе правильного файла шаблона и соответствующего wsu:id, основываясь на используемых в конфигурации WCF-клиента связывании и маркерах.

На рисунке 15 показано несколько файлов шаблонов вместе с определенными в них wsu:id. Например, файлы шаблонов под названием wsp-sp-<version>-<BindingSupported>.xml.

wsu:id в каждом из файлов шаблонов также следуют соглашениям по именованию. Например, wsp-sp-1-2-ws2007HttpBinding.xml использует соглашение <binding>-<token>-<is_sc_enabled>-<algorithmSuite>

Рисунок 15. Файлы шаблонов и wsu:id внутри них
Рисунок 15. Файлы шаблонов и wsu:id внутри них
Рисунок 15. Файлы шаблонов и wsu:id внутри них

Заключение

В данной статье был рассмотрен базовый сценарий взаимодействия DataPower и WCF .NET-клиента с использованием маркеров Kerberos и WSHttpBinding/WS2007HttpBinding. В ней было объяснено использование WebSphere DataPower для переноса функций защиты с Web-сервера. Статья состоит из трех разделов, в которых подробно рассмотрены следующие темы: a) подготовка среды Kerberos, б) настройка WCF .NET-клиента и в) настройка устройства Websphere DataPower. Также в ней объяснялось, как сделать возможным защищенный обмен в клиентском приложении и в устройстве DataPower. В разделе "Устранение неисправностей" были рассмотрены типичные программные ошибки и представлены варианты решения различных проблем, которые могут возникнуть во время настройки Windows-клиента или устройства DataPower. Наконец, в статье были освещены новые возможности, добавленные в версию 3.8.0 WebSphere DataPower.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы, WebSphere
ArticleID=862160
ArticleTitle=Передача функций защиты Web-сервисов на платформе WebSphere устройствам IBM WebSphere DataPower SOA Appliance: Часть 5. Настройка прокси Web-сервисов на взаимодействие с WCF .NET-клиентом
publish-date=03212013