Технология Клиент-Сервер 2005'2

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Гарантируя целостность SOAP-сообщения

Автор: Майк Лехманн
Материал предоставили: журнал Oracle Magazine
no.2
2005
Опубликовано: 28.02.2006

В моей предыдущей статье я представил WS-Security, спецификацию обеспечения безопасности Web-сервисов, и ее реализацию в сервере приложений Oracle Application Server 10g Release 10.1.3. Акцент был сделан на основах концептуальной модели WS-Security, в рамках которой безопасность, а именно аутентификация (authentication), была реализована в самом SOAP-сообщении, а не с помощью повторного использования механизма аутентификации протокола HTTP.

В этой же статье акцент будет сделан на цифровые подписи в WS-Security, гарантирующие получателю, что отправитель действительно отправил именно это сообщение, и оно не было изменено по дороге.

Вы можете подумать, что для того, чтобы это гарантировать, нужно кодировать (encrypt) данное сообщение, но, хотя кодирование может гарантировать конфиденциальность сообщения (уверенность, что никто не сможет его прочитать), оно само по себе не гарантирует целостности (уверенности, что сообщение не было изменено по дороге). Кроме того, кодирование не идентифицирует отправителя сообщения.

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

Цифровые подписи

Среда выполнения (runtime) для WS-Security в сервере Oracle Application Server – часто называемая “трубопровод” (pipeline) – требует добавления токенов аутентификации (authentication tokens), когда сообщение отправляется от клиента, то есть оно снабжается цифровой подписью и затем само кодируется. На стороне сервера эта процедура выполняется в обратном порядке.

Чтобы цифровые подписи и кодирование заработали, и у клиента, и у сервера должно быть одно хранилище ключей – частных ключей для подписания и кодирования своих сообщений и публичных ключей соответствующих партнеров для проверки подписей и раскодирования их сообщений. Управление этими ключами ведется сертификационным органом, таким как провайдеры сертификатов сервера Oracle Application Server или независимые провайдеры сертификатов.

Ключи должны храниться, как правило, в хранилище сертификатов и на стороне клиента, и на стороне сервера. В случае серверов J2EE-приложений место хранения – это часто стандартный JDK файл, называемый keystore – хранилищем ключей, и наиболее продвинутые реализации таких хранилищ также поддерживают серверы LDAP-директорий, такие как Oracle Internet Directory в качестве репозитория сертификатов.

Конфигурирование цифровых подписей

Учитывая весь этот контекст, я предпочту начинать не с Oracle JDeveloper (как я делал в предыдущих статьях), конфигурируя сервис для цифровых подписей. Я начну с сервера входящих сообщений, а потом прейду к клиенту – источнику выходящих сообщений. Используя тот же самый пример сервиса – HR Service, что и в моих предыдущих статьях, сначала я иду к странице Application Server Control Web services page (можно найти ее на вашей локальной установке OC4J на http://127.0.0.1:1810/ console/ias/oc4j/webservices) и потом перехожу к странице администрирования EmpServicePort administration page. Затем я редактирую установки обеспечения безопасности входящих сообщений (inbound security settings) как показано на рисунке 1.


Рисунок 1. Установка конфигурации цифровой <BR/>подписи для EmpService с использованием Application Server Control.

Вторая таблица установок обеспечения безопасности позволяет администраторам конфигурировать целостность сообщений (message integrity), иначе это называется конфигурированием цифровой подписи. Они могут простым образом устанавливать, что сообщения должны быть снабжены цифровыми подписями для того, чтобы быть обработанными, и они могут задать поддержку для нескольких стандартных алгоритмов, используемых для обработки цифровых подписей, включая DSA-SH1, HMAC-SHA1, RSA-MD5 и RSA-SHA1.

Чтобы упростить управление сертификатами, я использую хранилище ключей, поставляемое с Oracle Application Server 10g Release 10.1.3, oraks.jks, размещенное в директории <ORACLE_HOME>\j2ee\config. Оно уже содержит предварительно сгенерированные сертификаты для цифровых подписей – orasign – и сертификаты, предварительно сгенерированные для кодирования – oraenc. Переходя к соответствующему экрану компонента Application Server Control – the Keystore and Identity Certificates screen, – вы можете выбрать это хранилище ключей.

Результат этого конфигурирования показан в листинге 1, в файле wsmgmt.xml, репозитории времени выполнения для конфигурирования политик обеспечения безопасности. Он иллюстрирует задание интервалов (the rendering of the timestamp) и алгоритмов работы с подписями на XML в субэлементе <inbound> конфигурации HR-Emp-WS <port> configuration. Конфигурация хранилища ключей в oraks.jks задана в элементе <runtime> внизу файла wsmgmt.xml.

Листинг 1: Конфигурация цифровой подписи для EmpService

<wsmgmt 
  xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation =
  "http://xmlns.oracle.com/oracleas/schema/oracle-webservices-management-10_0.xsd">
  <port app = "HR-Emp-WS" 
    web = "WebServices" service="EmpService" port="EmpServicePort">
    <runtime enabled="security">
      <security>
        <inbound>
          <verify-signature>
            <signature-methods>
              <signature-method>DSA-SHA1</signature-method>
              <signature-method>HMAC-SHA1</signature-method>
              <signature-method>RSA-MD5</signature-method>
              <signature-method>RSA-SHA1</signature-method>
          </signature-methods>
           <tbs-elements>
           <tbs-element name-space="http://schemas.xmlsoap.org/soap/envelope/" 
                        localpart="Body"/>
            </tbs-elements>
            <verify-timestamp expiry="60" created="true"/>
          </verify-signature>
        </inbound>
      </security>
    </runtime>
  </port>
  <runtime>
    <security>
      <key-store path="C:\oc4j1013\j2ee\config\oraks.jks" 
                 name="oracle-keystore" type="JKS" 
                 store-pass="->default.keystore.config/oraks.jks"/>
      <signature-key alias="orasign" key-pass="->default.key.orasign"/>
      <encryption-key alias="oraenc" key-pass="->default.key.oraenc"/>
      <jaas-loginmodule-config>oracle.security.wss.jaas.JAASAuthManager
      </jaas-loginmodule-config>
      <nonce-config cache-ttl="300" clock-skew="300"/>
    </security>
  </runtime>
</wsmgmt>

Конфигурируйте клиента, отправляйте сообщение

Чтобы сконфигурировать клиент, вы должны создать симметричный конфигурационный файл на стороне клиента. Oracle JDeveloper 10g Release 10.1.3 предоставляет симметричные экраны, когда клиент — отправитель, в этом случае запускается генерация цифровой подписи. Рисунок 2 показывает декларирование, задание хранилища ключей, используемого клиентом (в этом случае, то же самое хранилище ключей, ради упрощения) для генерации цифровых подписей в Oracle JDeveloper.


Рисунок 2.

После завершения конфигурирования для работы с цифровыми подписями на сервере и клиенте, сообщение можно отослать и проинспектировать “на лету” (inspected on the wire), используя тот же самый клиент Web-сервиса — хотя конфигурация на стороне клиента отлична от конфигурации на стороне сервера. Листинг 2 показывает конфигурацию этого сервиса на стороне клиента, зеркальное отображение конфигурации на стороне сервера.

Листинг 2: Конфигурация цифровой подписи на стороне клиента

<?xml version = '1.0' encoding = 'UTF-8'?>
<port-info xmlns = "http://xmlns.oracle.com/oracleas/schema/oracle-webservices-client-10_0.xsd">
   <runtime xmlns = "" enabled="security">
      <security>
         <key-store path = "C:j1013ee.jks"
                    store-pass = "oracle"/>
         <signature-key alias = "orasign" key-pass = "orasign"/>
         <inbound/>
         <outbound>
            <signature>
               <signature-method>
                  RSA-SHA1
               </signature-method>
               <tbs-elements>
                  <tbs-element local-part = "Body"
                    name-space="http://schemas.xmlsoap.org/soap/envelope/"/>
               </tbs-elements>
               <add-timestamp created="true" expiry="60"/>
            </signature>
         </outbound>
      </security>
   </runtime>
   <operations xmlns = "">
      <operation name = "getEmpSalary"/>
   </operations>
</port-info>

Листинг 3 показывает цифровую подпись, прикрепленную к этому исходящему сообщению. Отметим, что цифровые подписи не изменяют содержания собственно сообщений. В низу этого листинга вы видите данные сообщения — в данном случае, номер служащего 7902— и заголовки этого сообщения содержат информацию об используемом алгоритме кодирования и о самой цифровой подписи.

Листинг 3: Исходящее сообщение от клиента

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:ns0="http://server.omag.com">
  <env:Header>
    <wsse:Security 
      xmlns = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
               wssecurity-secext-1.0.xsd" 
      xmlns:wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                    wssecurity-secext-1.0.xsd"
      xmlns:env = "http://schemas.xmlsoap.org/soap/envelope/" 
                   env:mustUnderstand="1">
        <wsse:BinarySecurityToken 
          xmlns = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                   wssecurity-secext-1.0.xsd" 
          xmlns:wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                        wss-wssecurity-secext-1.0.xsd" 
          ValueType = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                       x509-token-profile-1.0#X509v3" 
          EncodingType = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                          wss-soap-message-security-1.0#Base64Binary" 
          wsu:Id = "_HzmTOSPjEtTECx4NgnVZFA22" 
          xmlns:wsu = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                       wssecurity-utility-1.0.xsd">
MIICPDCCAaUCBEDP/wMwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxGzAZ
BgNVBAoTEk9yYWNsZSBDb3Jwb3JhdGlvbjEnMCUGA1UECxMeRk9SIERFTU8vVEVT
VElORyBQVVJQT1NFUyBPTkxZMRAwDgYDVQQDEwdvcmFzaWduMB4XDTA0MDYxNjA4
MDQxOVoXDTA5MDYxNTA4MDQxOVowZTELMAkGA1UEBhMCVVMxGzAZBgNVBAoTEk9y
YWNsZSBDb3Jwb3JhdGlvbjEnMCUGA1UECxMeRk9SIERFTU8vVEVTVElORyBQVVJQ
T1NFUyBPTkxZMRAwDgYDVQQDEwdvcmFzaWduMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCmiF9F708UHqLue1kVlwx22JVY/CB8fv0WnmMa/T0xwI/LMBDNvxAN
pXnszXj5wpiVyHyQgyvZTFGh1mGSxIrWGolVnl7MZDxAJ7Kq0PyQZkq6RonvFryv
uGPWxhaLdpx+QSQ/tMp2CV7qROwOjxv0LseoqpnIL8FHPP5tFeeRrwIDAQABMA0G
CSqGSIb3DQEBBQUAA4GBAHSxoaWx3spGSMvLzr4NKr4g3gAZaTWJpeOMvybuC0r7
UDf1FBGSyK5jnDoLzhobVgxlbB9x+Voikp2bKGfxrcd9GBxlIjpfXfs9qUrJphH/
m+gwGyBFCv7ThSyiFxP1d2QPeOK76KsUl72MBerrTc0zmbR0l/2PuV4P9Yp8ZbCO

</wsse:BinarySecurityToken>
      <dsig:Signature 
        xmlns=http://www.w3.org/2000/09/xmldsig#
        xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
          <dsig:SignedInfo>
            <dsig:CanonicalizationMethod 
              Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
               <dsig:SignatureMethod 
                 Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
               <dsig:Reference URI="#B1L8xNs19hFFr8h14Dg61A22">
                  <dsig:DigestMethod 
                    Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                  <dsig:DigestValue>
                    32itvZuzsC1J/8waP2pdXvBqVmo=</dsig:DigestValue>
                </dsig:Reference>
          </dsig:SignedInfo>
            <dsig:SignatureValue>
NJWb7FnNzf3fvL9GtuRjsa49BPRV1JAWsq6+BEL5KXfhL8EX2pyOM2PgFpTfesyUeICSsBE5ngkizUC
hH71U8MDWFffFL8Kcygz7mZBmCsP6Ymgo555QXNgKS+OBe/gwINwdZHjxhMFZchJDim18QRJ102lJkr
eOwuxmFd1DSiw=
            </dsig:SignatureValue>
            <dsig:KeyInfo>
               <wsse:SecurityTokenReference 
                 xmlns = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                          wss-wssecurity-secext-1.0.xsd" 
                 xmlns:wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-
                               200401-wss-wssecurity-secext-1.0.xsd" 
                 wsu:Id = "_DvCDC7tZtfC1llyHXQd0MQ22"
                 xmlns:wsu = "http://docs.oasis-open.org/wss/2004/01/oasis-
                              200401-wss-wssecurity-utility-1.0.xsd">
                  <wsse:Reference 
                    xmlns = "http://docs.oasis-open.org/wss/2004/01/oasis-
                             200401-wss-wssecurity-secext-1.0.xsd" 
                    xmlns:wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-
                                200401-wss-wssecurity-secext-1.0.xsd" 
                    URI = "#_HzmTOSPjEtTECx4NgnVZFA22"/>
               </wsse:SecurityTokenReference>
            </dsig:KeyInfo>
         </dsig:Signature>
         <wsse:UsernameToken 
           xmlns = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                    wssecurity-secext-1.0.xsd" 
           xmlns:wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                         wss-wssecurity-secext-1.0.xsd" 
           wsu:Id = "oxV2WMaYOo60hpvetEbUcg22" 
           xmlns:wsu = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                        wss-wssecurity-utility-1.0.xsd">
            <wsse:Username/>
            <wsse:Nonce>HaebkIwUeunnEPbIjkwM1g==
</wsse:Nonce>
            <wsu:Created 
              ValueType="http://www.w3.org/2001/XMLSchema/dateTime">
              2005-01-02T07:41:06Z
            </wsu:Created>
         </wsse:UsernameToken>
         <wsu:Timestamp 
           xmlns = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                    wssecurity-secext-1.0.xsd" 
           xmlns:wsse = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                         wss-wssecurity-secext-1.0.xsd" 
           wsu:Id = "GQZL0jR9jDW6Sh7RoCLsBw22" 
           xmlns:wsu = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-
                        wss-wssecurity-utility-1.0.xsd">
            <wsu:Created ValueType="http://www.w3.org/2001/XMLSchema/dateTime">
              2005-01-02T07:41:06Z
            </wsu:Created>
            <wsu:Expires ValueType="http://www.w3.org/2001/XMLSchema/dateTime">
              2005-01-02T15:41:06Z
            </wsu:Expires>
      </wsu:Timestamp>
    </wsse:Security>
  </env:Header>
  <env:Body wsu:Id="B1L8xNs19hFFr8h14Dg61A22" 
    xmlns:wsu = "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
                 wssecurity-utility-1.0.xsd">
      <ns0:getEmpSalaryElement>
         <ns0:String_1>7902</ns0:String_1>
      </ns0:getEmpSalaryElement>
   </env:Body>
</env:Envelope>

Следующие шаги обеспечения безопасности

В этой статье представлена спецификация WS-Security с кратким введением цифровых подписей. Акцент был сделан на подтверждении идентичности отправителя и гарантировании целостности сообщений. Вы можете использовать аналогичную конфигурацию с тем же самым подходом – использованием криптографии и публичного ключа – для кодирования содержания сообщения. Чтобы поработать с примером из этой статьи, скачайте Oracle Application Server 10g Release 10.1.3 Developer Preview из сети OTN.

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

Copyright © 1994-2016 ООО "К-Пресс"