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

Примеры WS-Secure Conversation

В данной статье мы расширим предыдущий сценарий, развернув WebSphere DataPower SOA Appliance в сценарии обмена, основанном на стандарте WS-Secure Conversation. WebSphere DataPower SOA Appliance будет обрабатывать функциональность WS-Security сервера приложений после установки контекста системы защиты в соответствии с политикой WS-Security Policy.

Шиу Фунь Пунь, старший технический руководитель, IBM

Шиу Фунь Пунь (Shiu Fun Poon) является техническим руководителем группы IBM WebSphere DataPower Security. Она интересуется всеми аспектами SOA. Разрабатывает функциональность, обеспечивающую поддержку WS-Security в соответствии с рекомендациями OASIS, W3C, WS-Security Policy, а также другие дополнительные функции IBM WebSphere DataPower Appliance, связанные с безопасностью. Принимает участие в совершенствовании характеристик надежности, готовности и обслуживаемости (RAS) этих устройств. До этого руководила группой Domino Security Team.



Мериэн Хондо, старший технический сотрудник, IBM

Мериэн Хондо (Maryann Hondo) - старший технический сотрудник в IBM WebSphere Technical Institute, занимается устройствами WebSphere DataPower Appliance, архитектурами SOA, политикой SOA и защитой SOA. Ранее работала в организации IBM Enterprise Services над продвижением SOA, концентрируясь на сервисах безопасности. Она является соавтором спецификаций WS-Security, WS-Trust, WS-SecureConversation, WS-Policy и WS-Federation, разработанных IBM и другими бизнес-партнерами в рамках плана Web Services Security Roadmap.



27.03.2012

Введение

В 2002 году небольшая группа сотрудников IBM и группа сотрудников Microsoft подготовили документ, описывающий поэтапный выпуск спецификаций технологии защиты XML, предназначенных для поддержки защищенных сценариев работы Web-сервисов. Сегодня стало ясно, что основа была заложена серьезная. SOAP и WS-Security являются общепризнанными и реализованными стандартами. WS-Policy и WS-Trust также стали стандартами в W3C и OASIS соответственно и являются обычными функциями в защищенных средах Web-сервисов. WS-Privacy, WS-Federation и WS-Authorization столкнулись с рыночной конкуренцией. Эта модель Web-сервисов была предназначена для предоставления разработчикам SOA-приложений общего набора сервисов безопасности, используемых независимо или в композитных приложениях, чтобы не реализовывать в коде каждого приложения или сервиса свою собственную защиту. Недавно были стандартизированы два других направления – политики WS-Secure Conversation и WS-Security. WS-Secure Conversation описывает установку ключей сеанса (session keys), производных ключей (derived keys) и ключей отдельных сообщений (per-message keys) для защищенного взаимодействия двух участников в длительной транзакции или сеансе обмена; таким образом оптимизируется согласование защиты отдельного сообщения. WS-Secure Conversation предназначена для осуществления длительного обмена на основе WS-Security и WS-Trust. В документе поэтапного выпуска спецификаций был определен набор сценариев для Secure Conversation (Enabling Federation, Supporting Validation Services, Delegation, Access Control), а работа, описанная ниже представителями организаций по разработке и поддержке WebSphere DataPower, является подтверждением их реальности.

Сегодня стало ясно, что основа была заложена серьезная. SOAP и WS-Security являются общепризнанными и реализованными стандартами. WS-Policy и WS-Trust также стали стандартами в W3C и OASIS соответственно и являются обычными функциями в большинстве защищенных сред Web-сервисов. WS-Privacy, WS-Federation и WS-Authorization столкнулись с рыночной конкуренцией со стороны инициатив, связанных с решениями для единого входа (Single Sign On), и основанных на подлинности программными моделями, таких как Liberty/SAML. Кроме того, продолжающаяся эволюция Web-приложений (от статических Web-страниц к моделям доступа на основе REST и AJAX с динамическим содержимым) побуждает Web-разработчиков и разработчиков облачных решений исследовать альтернативные стратегии защиты, такие как OAuth и OpenID. Эта модель Web-сервисов была предназначена для предоставления разработчикам SOA-приложений общего набора сервисов безопасности, используемых независимо или в композитных приложениях, чтобы не реализовывать в коде каждого приложения или сервиса свою собственную защиту посредством программных интерфейсов. Однако все еще существует множество интерфейсов и стратегий для разработчиков, и при непрекращающейся потребности в Web-приложениях для социальных сетей по-прежнему приходится делать выбор между парадигмами "Web-приложение" и "Web-сервис".

Недавно были стандартизированы два других направления – WS-Secure Conversation и WS-Security. WS-Secure Conversation описывает установку ключей сеанса (session keys), производных ключей (derived keys) и ключей отдельных сообщений (per-message keys) для защищенного взаимодействия двух участников в длительной транзакции или сеансе обмена; таким образом оптимизируется согласование защиты отдельного сообщения. Secure Conversation позволяет Web-сервисам описывать, как сервис может передавать защищенный контекст (определенный набор утверждений об атрибутах защиты и связанных с ними данных), основываясь на концепциях генерирования маркера доступа и механизмах обмена, определенных в базовых спецификациях WS-Security и WS-Trust. Используя эти механизмы, Web-сервис делает возможным длительный обмен данными и может наложить такой "обмен данными" на существующий http-протокол транспортного уровня. Длительный обмен позволяет использовать операции симметричной криптографии для защиты сообщений на протяжении установленного сеанса. Операции симметричной криптографии более эффективны, чем стандартные операции асимметричной криптографии.

Существует много сценариев, в которых необходимы возможности защиты, предоставляемые Secure Conversation. В документе поэтапного выпуска спецификаций определяется их набор:

  • Enabling Federation (создание условий для федерирования).
  • Supporting Validation Services (сервисы вспомогательной верификации).
  • Delegation (делегирование).
  • Access Control (управление доступом).

Сценарий Secure Conversation

Технические и бизнес-данные для этого сценария предоставили Рене Кисслинг (Rene Kiessling), Мануэль Романн (Manuel Rohmann), Мэт МакЛарти (Matt McLarty) и Гэри Сингх (Gari Singh). В данной статье мы исследуем сценарий организации Federated Secure Conversation (обмена с использованием федеративной защиты), в котором доверительные отношения устанавливаются между WebSphere DataPower STS (выступающим в качестве прокси поставщика сервиса - SP) и Microsoft Identify Provider (IdP). Для WebSphere DataPower это иллюстрация реализации пользовательского сценария использования инфраструктур политики WebSphere DataPower с клиентом Microsoft, использующим wsFederationHttpBinding Microsoft. Чтобы обеспечить выполнение политики безопасности Web-сервиса, необходимой для защищенного обмена, используется WebSphere DataPower SOA Appliance. Для реализации сценария необходимы:

  • Microsoft WCF .Net 3.5 Framework.
  • WebSphere DataPower Firmware Release 3.7.3.3 или более новой версии.
  • Любой сервер приложений; в данном случае мы будем использовать WebSphere Application Server.

Приложение определяет требование для Secure Conversation (это можно реализовать путем прикрепления политики безопасности к WSDL-файлу приложения) между поставщиком приложения и клиентом. Для установки Secure Conversation устройству WebSphere DataPower SOA Appliance необходимы:

  1. Возможность выполнить аутентификацию клиента путем проверки цифровой подписи SAML 1.1 (для данного примера). Может понадобиться дополнительная настраиваемая обработка для работы со специальным сценарием (см. раздел "Другие соображения" в конце данной статьи).
  2. Возможность доверять IdP, сгенерировавшему SAML-маркер (Microsoft IdP).
  3. Возможность генерировать маркер защищенного обмена, который WebSphere DataPower и Microsoft WCF-клиент могли бы использовать для защиты сообщений.

Обмен между участниками включает в себя следующие взаимодействия:

  1. Клиент Microsoft WCF .Net 3.5 устанавливает связь с поставщиком идентификации (Identity Provider, IdP) для запроса маркера SAML 1.1 (это реализация сценария "federation").
  2. IdP выдает маркер SAML1.1 клиенту Microsoft WCF .Net 3.5:
    - MS IdP подписывает выданный маркер.
  3. Клиент Microsoft WCF .Net 3.5 обращается к Web-сервису через WebSphere DataPower.
  4. В реальном потоке сообщений приложения WebSphere DataPower, выступающее в роли STS, выдаст маркер Secure Conversation Token для клиента Microsoft WCF .Net 3.5.
  5. Трафик защищается маркером Secure Conversation Token, полученным на шаге 4.
  6. После завершения обмена сообщениями в рамках защищенного сеанса клиент посылает операцию Cancel в WebSphere DataPower для уведомления о завершении этого сеанса.
Рисунок 1. Обмен сообщениями во время сеанса защищенного обмена
Рисунок 1. Обмен сообщениями во время сеанса защищенного обмена

Шаг 1. Настройка клиента

Для клиента (WCF) необходим соответствующий app.config:

Листинг 1. Файл app.config для настройки клиента
<bindings>
      <wsFederationHttpBinding>
        <binding name="EchoUserWithoutTlsNego" closeTimeout="00:05:00"
                 openTimeout="00:05:00" receiveTimeout="00:30:00"                
                 sendTimeout="00:05:00">
         <security mode="Message">
            <message issuedTokenType=
                    "http://docs.oasis-open.org/wss/
                            oasis-wss-saml-token-profile-1.1#SAMLV1.1"
                     negotiateServiceCredential="false" >
              <issuer address="http://localhost:6000/SimpleActiveSTS"              
                      binding="wsHttpBinding" bindingConfiguration=
                        "http://localhost:6000/SimpleActiveSTS">
                <identity>
                  <userPrincipalName value="DEMOSERVER\Administrator" />
                </identity>
              </issuer>
              <issuerMetadata address="http://localhost:6000/SimpleActiveSTS/mex" />
              <claimTypeRequirements>
                <add claimType="http://schemas.xmlsoap.org/ws/
                                        2005/05/identity/claims/name"  />
                <add claimType="http://schemas.datapower.com/E8/
                                        2008/09/Identities/RZUserId" />
              </claimTypeRequirements>
            </message>
          </security>
        </binding>
      </wsFederationHttpBinding>
      
      <wsHttpBinding>
        <!-- взаимодействие с локальным STS-сервисом -->
        <binding name="http://localhost:6000/SimpleActiveSTS" closeTimeout="00:05:00"
            openTimeout="00:05:00" receiveTimeout="00:30:00" sendTimeout="00:05: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" maxNameTableCharCount="16384" />
          <reliableSession ordered="true" inactivityTimeout="00:30:00"
              enabled="false" />
          <security mode="Message">
            <transport clientCredentialType="Windows" proxyCredentialType="None"
                realm="" />
            <message clientCredentialType="Windows" negotiateServiceCredential="true"
                algorithmSuite="Default" establishSecurityContext="true" />
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>

    <client>
      <!-- DNS-имя конечной точки datapower,
	   настроенной внутри файла local hosts [8000] -->
      <endpoint name="EchoUser.DataPower"
                address="http://datapower:8000/EchoService"
                binding="wsFederationHttpBinding"
                bindingConfiguration="EchoUserWithoutTlsNego"
                contract="DataPower.CC.DCWebService.Common.EchoUser">
        <identity>
          <certificateReference storeName="TrustedPeople"
                                storeLocation="CurrentUser"
                                x509FindType="FindBySubjectName"
                                findValue="datapower" />
        </identity>
      </endpoint>
    </client>

Шаг 2. Настройка SOA Appliance

В спецификациях WS-Secure Conversation определены три способа установки контекста защиты между двумя участниками. В данном сценарии доверительные отношения c SOA Appliance устанавливаются согласно первому из этих шаблонов. Microsoft IdP генерирует маркер аутентификации, а WebSphere DataPower распознает этот IdP как доверенного участника. Таким образом, SOA Appliance выступает в роли STS для SP и создает маркер доступа для обмена между аутентифицированным инициатором обмена и приложением.

Среда

MMC – это инструментальная программа Microsoft для управления ключами, которая используется для экспорта ключей из Microsoft. После экспорта из Microsoft все ключи необходимо импортировать в WebSphere DataPower, чтобы можно было применять их для дешифрования и проверки сообщений во время начального обмена данными RST/RSTR между клиентом Microsoft .Net и WebSphere DataPower.

Для установки доверительных взаимоотношений WebSphere DataPower импортирует в устройство сертификаты (или открытый ключ) в формате DER, PEM, PKCS#7 или PKCS#12. При импорте в SOA Appliance закрытого ключа файл должен иметь формат DER, PEM, PKCS#8 или PKCS#12. Microsoft экспортирует ключи в формате pfx, а для преобразования формата pfx используется программа openssl. Например, openssl pkcs12 –in cert.pfx –out cert.pem -nodes.

Чтобы настроить защищенный обмен на WebSphere DataPower SOA Appliance, в WSDL-сервис нужно добавить новую операцию, обрабатывающую операцию RequestSecurityToken. Этот WSDL-файл определяет операцию wsdl:operation для RequestSecurityToken с пространством имен soap12. Пространство имен должно соответствовать пространству имен SOAP операции wsdl:operation.


Новые функциональные возможности WebSphere DataPower 3.7.3

В версии 3.7.3 имеются некоторые новые функциональные возможности, позволяющие настроить WebSphere DataPower на работу в данном сценарии. Примечание. Поддержка Secure Conversation с WS-Security Policy в WebSphere DataPower:

  • поддерживается только режим enforce;
  • возобновление (renewal) маркера не поддерживается.
  1. Для улучшения поддержки EncryptedKeySHA1 KeyIdentifier и сохранения дешифрованных ключей в Web Service Proxy были добавлены два параметра.

Чтобы увидеть их, выберите WSProxy > Proxy Settings > EncryptedKeySHA1 Cache Lifetime и Preserve EncryptedKey Chain. На рисунке 2 показан графический пользовательский интерфейс (GUI).

Рисунок 2. Обновленный графический пользовательский интерфейс в версии 3.7.3
Рисунок 2. Обновленный графический пользовательский интерфейс в версии 3.7.3

EncryptedKeySHA1 Cache: время жизни кэш-памяти в секундах, определяющее, как долго кэшируется дешифрованная информация Encrypted Key. Этот параметр необходим для генерирования ответа с идентификатором EncyrptedKeySHA1 Key Identifier или дешифрования будущего обмена данными, защищенного с использованием EncryptedKeySHA1 Key Identifier.

Preserve EncryptedKey Chain: по умолчанию DataPower будет удалять информацию о ключах после дешифрования. При установке этого параметра в on информация о ключе сохраняется для следующей операции (например, когда сообщение запроса подписывается и шифруется тем же самым ключом, а после дешифрования сообщения этот же ключ необходим для проверки цифровой подписи сообщения).

  1. Новый параметр политики, Additional Transform Action During BootstrapPolicy, позволяет выполнять специализированное преобразование в процессе начальной загрузки. Любая таблица стилей, указанная в этом параметре, будет выполняться в конце действий STS RST и перед всеми действиями для RSTR (см. рисунок 2).
Рисунок 3. Параметр политики в версии 3.7.3
Рисунок 3. Параметр политики в версии 3.7.3
  1. В dp:aaa-set-context-info и dp:aaa-get-context-info добавлен новый смешанный контекст transaction-misc для хранения смешанной информации, связанной с контекстом. Размер данных, которые может содержать этот контекст, ограничен 512 байтами.
  2. В версии 3.7.3 изменилось поведение относительно того, какая политика должна прикрепляться к wsdl:operation, RequestSecurityToken.
  • До версии 3.7.3 операция wsdl:operation name="RequestSecurityToken" использовала связывание начальной загрузки (bootstrap bindings), ассоциированное с sp:BootstrapPolicy в элементе PolicyReference, как показано в следующем примере:
<wsdl:operation name="RequestSecurityToken">
<wsp:PolicyReference URI="local:///policy.xml#bootstrap-binding" />
<wsdl:input message="tns:RequestSecurityToken" />
<wsdl:output message="tns:RequestSecurityTokenResponse" />
</wsdl:operation>
  • В версии 3.7.3.x операция wsdl:operation name="RequestSecurityToken" должна использовать связывание приложения (application binding) в элементе PolicyReference, как показано в следующем примере:
<wsdl:operation name="RequestSecurityToken">
<wsp:PolicyReference URI="local:///policy.xml#application-binding" />
<wsdl:input message="tns:RequestSecurityToken" />
<wsdl:output message="tns:RequestSecurityTokenResponse" />
</wsdl:operation>
  • До версии 3.7.3 месторасположение элемента PolicyReference в WSDL-файле было произвольным. В 3.7.3 он должен непосредственно следовать за элементом операции, атрибут name которого имеет значение RequestSecurityToken, как показано в предыдущем примере.

В WebSphere DataPower версии 3.7.3 включен новый шаблон для реализации данного сценария. Шаблон можно найти по адресу store:///policies/templates/dotnet/wsp-sp-1-2-wsFederationHttpBinding.xml, а процесс настройки сервиса на использование этого связывания рассмотрен ниже.


Настройка SOA Appliance на обработку wsFederationHttpBinding

  1. Загрузите данные о ключах, экспортированные из Microsoft, в WebSphere DataPower SOA appliance Control Panel > Keys and Certicates Management > [Keys][Certificates][Crypto Profile > Identification Credentials][Crypto Profile > Validation Credentials] Keys: datapower [из данных о ключах, указанных в app.config -> "<client/> section"] Certificates: datapower [из данных о ключах, указанных в app.config -> "<client/> section"] Identification Credentials: datapower [созданы с указанными выше ключом и сертификатом] [не обязательно] Validation Credentials: sts [из данных о ключах, которые Identifier Provider использовал для подписи SAML 1.1].
  • Если soap:Body входящего сообщения зашифрован, WSProxy автоматически дешифрует soap:Body перед тем, как направить его в соответствующую wsdl:operation. Существует 2 способа указать ключ для дешифрования:
    1. WSProxy > Proxy Settings > Decrypt Key.
    2. Создание Identification Credential для связи с открытым и закрытым ключами (это предпочтительный метод, и мы будем использовать его в данном сценарии).
Рисунок 4. Список криптографических сертификатов
Рисунок 4. Список криптографических сертификатов
Рисунок 5. Список криптографических ключей
Рисунок 5. Список криптографических ключей
Рисунок 6. Удостоверения идентификации (Identification Credentials)
Рисунок 6. Удостоверения идентификации (Identification Credentials)
Рисунок 7. Удостоверения проверки достоверности (Validation Credentials)
Рисунок 7. Удостоверения проверки достоверности (Validation Credentials)
  1. Извлеките WSDL-файл с сервера приложений. В данном случае это можно сделать, указав адрес http://<сервер>:<порт>?wsdl.
  2. Измените wsdl на wsdl:Input и wsdl:Output для прикрепления политики входящих и исходящих сообщений.
	<wsdl:binding name="EchoUser" type="i0:EchoUser">
	    <soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/>
	    <wsdl:operation name="getCurrentUser">
             <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                    wsp-sp-1-2-wsFederationHttpBinding.xml#BindingPolicy”/>  
	     <soap12:operation soapAction=
                "http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT" 
                    style="document"/>
	      <wsdl:input name="getCurrentUserRequest">
                <wsp:PolicyReference URI=
                 "store:///policies/templates/dotnet/
                    wsp-sp-1-2-wsFederationHttpBinding.xml#InputPolicy"/> 
	       <soap12:body use="literal"/>
	      </wsdl:input>
	      <wsdl:output name="getCurrentUserResponse">
                <wsp:PolicyReference URI=
                 "store:///policies/templates/dotnet/
                    wsp-sp-1-2-wsFederationHttpBinding.xml#OutputPolicy"/> 
	       <soap12:body use="literal"/>
	      </wsdl:output>
	    </wsdl:operation>
	</wsdl:binding>
  1. Создайте WSProxy с использованием WSDL-файла предыдущего шага.
  • Создайте набор параметров WS-Policy, secpol-param:
    - wsFederationHttpBinding от Microsoft использует WS-Security Policy 1.1 http://schemas.xmlsoap.org/ws/2005/07/securitypolicy, а ws2007FederationHttpBinding использует http://docs.oasis-open.org/ws-sz-ws-securitypolicy/200702. Из названия следует, что пространство имен политики безопасности имеет версию 1.2; однако используется пространство имен версии 1.1, и это влияет на то, как Security Policy Parameter связывается с WS-Security Policy. Поэтому определяются 2 набора параметров политики для обоих пространств имен: Security Policy 1.1 и Security Policy 1.2;
    - устанавливаются три параметра: Interoperable with, WS-SecureConversation Version и Verification Valcred.
  • Выберите Enforce в качестве режима WS-Policy Enforcement Mode.
  • Нажмите Next.
Рисунок 8. Параметры политики
Рисунок 8. Параметры политики
Рисунок 9. WSDL-файлы Web Service Proxy
Рисунок 9. WSDL-файлы Web Service Proxy
  1. Добавьте HTTP Front Side Handler:
    - Name: http8000;
    - Port Number: 8000.
Рисунок 10. HTTP Front Side Handler
Рисунок 10. HTTP Front Side Handler
Рисунок 11. Настройка HTTP Front Side Handler
Рисунок 11. Настройка HTTP Front Side Handler
Рисунок 12. Месторасположение исходного WSDL-файла
Рисунок 12. Месторасположение исходного WSDL-файла
  1. Укажите IP-адрес удаленного сервера, номер порта и URI сервиса приложений. Для данного примера IP-адрес хоста - 9.33.82.25, порт – 8000, URI - /EchoService.
  2. Добавьте WSDL-файл ws-wssecconv.wsdl для обработки STS RequestSecurityToken:
    - проверьте корректность политики безопасности, прикрепленной к соответствующему Policy Subject в ws-wssecconv.wsdl.
	  . . . . . . 
  <wsdl:portType name="Test">
    <wsdl:operation name="RequestSecurityToken">
      <wsp:PolicyReference URI=
            "store:///policies/templates/dotnet/
                wsp-sp-1-2-wsFederationHttpBinding.xml#BindingPolicy"/> 
      <wsdl:input message="tns:RequestSecurityToken"/>
      <wsdl:output message="tns:RequestSecurityTokenResponse"/>
    </wsdl:operation>
</wsdl:portType>
	   . . . . . .
	  <wsdl:input>
             <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                    wsp-sp-1-2-wsFederationHttpBinding.xml#InputPolicy"/> 
             <soap12:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
              <wsp:PolicyReference URI=
                "store:///policies/templates/dotnet/
                    wsp-sp-1-2-wsFederationHttpBinding.xml#OutputPolicy"/> 
              <soap12:body use="literal"/>
            </wsdl:output>
  • Используйте тот же Local Endpoint Handler (обработчик локальной оконечной точки), что и в пункте 5.
  • Используйте тот же URI, что и в пункте 5.
  1. Включите поддержку EncryptedKeySHA1 в WSProxy и сохраните информацию о ключах, отредактировав настройки в Proxy Settings:
    - EncryptedKeySHA1 Cache Lifetime: 100 [любое значение, превышающее 0 сек];
    - Preserve EncryptedKey Chain: on [для сохранения информации о ключах, необходимой для проверки цифровой подписи внутри сообщения].
Рисунок 13. Панель Configure Web Service Proxy
Рисунок 13. Панель Configure Web Service Proxy
  1. [необязательно] Прикрепите политику к операции приложения. В данном примере мы прикрепляем политику непосредственно в WSDL. Другим вариантом является использование интерфейса WebGUI для подключения политики:
    - выберите Yes для Show portType and binding nodes;
Рисунок 14. Show portType and binding nodes
Рисунок 14. Show portType and binding nodes

- выберите WS-Policy в portType для прикрепления политики к соответствующему Policy Subject;

- прикрепите store:///policies/templates/dotnet/wsp-sp-1-2-wsFederationHttpBinding.xml#BindingPolicy.

Рисунок 15. Additional Policy Sources
Рисунок 15. Additional Policy Sources
  1. Ответное сообщение подписано и зашифровано. После шифрования сообщения проверка корректности схемы будет завершаться неудачно при включении такой проверки.
  2. STS > RequestSecurityToken:
    - снимите отметку в полях Schema validate request messages (проверка корректности схемы в сообщениях запроса) и Schema validate response messages (проверка корректности схемы в сообщениях ответа).
  3. Application > EchoServices:
    - снимите отметку в поле Schema validate response messages.
Рисунок 16. Снятие отметки в поле Schema validate response messages
Рисунок 16. Снятие отметки в поле Schema validate response messages
  1. Добавьте, используя Add Rule, 2 пользовательских правила, request и response, к EchoUserServiceWCF.wsdl для обработки WS-Addressing.
  • Request [Client > Server]: добавьте преобразование для getMessage.xsl (см. ниже):
    - При этом в переменной контекста будет сохраняться необходимая wsa:xxxx информация;
    - Direction: Client to Server;
    - Input: INPUT;
    - Output: NULL.
  • Response [Server > Client]: добавьте преобразование для setMessage,xsl (см. ниже):
    - при этом создастся элемент <soap:Header/> с необходимой информацией WS-Addressing из пункта 10;
    - Direction: Server to Client;
    - Input: INPUT;
    - Output: PIPE.

    ** setMessage.xsl предполагает, что ответ сервера не содержит soap:Header. Т.е. будет добавляться soap:Header с необходимой информацией. Но если сервер отправляет ответ, содержащий soap:Header, следует использовать setMessageIdWithoutAddingSoapHeader.xsl.
Рисунок 17. Action: Transform
Рисунок 17. Action: Transform
  1. Нажмите Apply для активизации всех изменений и сохранения конфигурации WSProxy.

Тестирование соединения

На данном этапе следует изменить клиентское приложение Microsoft .Net WCF 3.5, чтобы оно имело доступ к устройству WebSphere DataPower SOA Appliance.

Рисунок 18. Установленный защищенный обмен
Рисунок 18. Установленный защищенный обмен

Мы успешно установили защищенный обмен с Microsoft WCF 3.5, используя wsFederationHttpBinding.

Для проверки корректности обмена данными с WebSphere DataPower SOA Appliance включите отладочный режим и монитор трафика. Вы увидите 3 фрагмента сетевого трафика. Ниже приведен пример:

Tran # 41121: STS RequestSecurityToken. Установился SecurityContextToken. Обратите внимание на outbound-url. Устройство SOA Appliance выступило в роли STS и сгенерировало маркер Secure Conversation Token для трафика приложения, следовательно, в этом трафике нет корректного outbound-url.

Tran # 41409: Application Traffic. Нужно иметь в виду, что в ответном трафике приложения первая проверка выполняется для soap:Fault, и, если все пройдет хорошо, отобразится сообщение о неудаче этой проверки, за которым последует еще один фрагмент (фрагменты) трафика приложения. Это ожидаемое поведение. * soap:Fault может иметь свою собственную Security Policy, не соответствующую политике трафика приложения. Следовательно, если приложение работает корректно без возврата soap:Fault, вы увидите сообщение о неудаче первой проверки.

Tran # 45170: Операция Cancel STS RequestSecurityToken. Сеанс защищенного обмена завершается. Обратите внимание на outbound-url. SOA Appliance выступает в роли STS для отмены маркера Secure Conversation Token, сгенерированного им в транзакции Tran #41121. Следовательно, в этом трафике нет корректного outbound-url.

Рисунок 19. Список транзакций для EchoService
Рисунок 19. Список транзакций для EchoService

Другие соображения

При использовании wsFederationHttpBinding от Microsoft первоначальный RST/RSTR содержит маркер идентификации (identity token) - маркер SAML1.1 в данном случае. Этот SAML-маркер используется при первоначальном обмене и не передается в дальнейшем трафике приложения. Ниже приведен пример, демонстрирующий, как можно сохранить эту информацию для дальнейшего трафика. Пример приведен только в демонстрационных целях.

Данный маркер SAML 1.1 отправляется только один раз, но должен быть сохранен для последующих транзакций приложения. Добавляется новый параметр политики безопасности - Additional Transform Action During BootstrapPolicy. Благодаря этому параметру можно использовать таблицу стилей после обработки RST, но до генерирования RSTR устройством DataPower SOA Appliance. Эта таблица стилей будет хранить информацию о SAML1.1 в кэш-памяти для дальнейшего трафика.

Рисунок 20. Additional Transform Action During BootstrapPolicy
Рисунок 20. Additional Transform Action During BootstrapPolicy

В статью включены три таблицы стилей, служащих примером использования Additional Transform Action During BootstrapPolicy в сочетании с dp:aaa-set-context-info. Вместе они связывают SAML-маркер с данной транзакцией защищенного обмена.

  1. Создайте указанные выше параметры для трафика RST/RSTR Bootstrap (см. StoreSAMLFromRST.xsl):
    - таблица стилей сохраняет подмножество информации SAML в переменной контекста.
  2. В пользовательском правиле RST/RSTR Bootstrap вызовите dp:aaa-set-context-info для связывания SAML-информации с контекстом Secure Conversation. Обратите внимание, что размер смешанной информации ограничен 512 байтами (см. AddSAMLToSecureContext.xsl):
    - параметр input этого преобразования должен быть установлен в INPUT;
    - параметр output этого преобразования должен быть установлен в NULL;
    - действие Result Action, следующее за этим преобразованием, должно иметь значение INPUT в своем параметре input.
  3. В настройках request traffic пользовательского правила трафика приложения:
    - используйте действие transform с dp:aaa-get-context-info для доступа к SAML-информации, сохраненной в пункте 1 (см. GetSAMLFromRST.xsl);
    - параметр input этого преобразования должен быть установлен в INPUT;
    - параметр output этого преобразования должен быть установлен в NULL;
    - действие Result Action, следующее за этим преобразованием, должно быть установлено соответствующим образом; вероятнее всего, это будет значение INPUT.

Загрузка

ОписаниеИмяРазмер
Примеры таблиц стилейstylesheets.zip10 КБ

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


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