Профессионалу разработчику

Майк Лехманн

Гарантируя целостность SOAP-сообщения
(Guarantee SOAP Message Integrity, By Mike Lehmann)

Источник: журнал Oracle Magazine, no.2, 2005, http://www.oracle.com/technology/oramag/oracle/05-mar/o25web.html

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

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

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

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

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

1. Отправитель вычисляет “одностороннее” (one-way) хэш-значение (hash value) на основе содержания SOAP-сообщения, используя один из нескольких хорошо известных хэш-алгоритмов. Они называются “односторонними”, так как нет способа реконструировать содержание сообщения исходя из этого хэш-значения.
2. Сообщение использует это хэш-значение вместе с криптографическим частным ключом отправителя для вычисления цифровой подписи.
3. Приняв сообщение, получатель использует публичный ключ отправителя для вычисления c целью определения действительности (validity) подписи сообщения и извлечения хэш-значения. Такого рода вычисление с цифровой подписью, созданной с применением частного ключа отправителя, гарантирует определение идентичности отправителя.
4. Применение того же самого алгоритма для определения хэш-значения на основе содержания сообщения удостоверяет, что это сообщение не было изменено по дороге к получателю.

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

Среда выполнения (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.

Вторая таблица установок обеспечения безопасности позволяет администраторам конфигурировать целостность сообщений (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. Переходя к соответствующему экрану -- the Keystore and Identity Certificates screen – компонента Application Server Control, вы можете выбрать это хранилище ключей.

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

Листинг 1: Конфигурация на XML цифровой подписи для 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.

После завершения конфигурирования для работы с цифровыми подписями на сервере и клиенте, сообщение можно отослать и проинспектировать “на лету” (inspected on the wire), используя тот же самый клиент Web-сервиса — хотя конфигурация на стороне клиента отлична от конфигурации на стороне сервера. Listing 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: Исходящее сообщение от клиента

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

Следующие шаги Скачайте Oracle Application Server 10g Release 10.1.3 Developer Preview

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

В моей следующей статье будет показано, как применять обеспечение безопасности к Web-сервисам не из среды Oracle, используя шлюз Web Services gateway как точку реализации политики безопасности (security policy enforcement point).

Майк Лехманн (Mike Lehmann) – директор корпорации Oracle по управлению продуктами для сред J2EE и Web-сервисов. Вы можете почитать его блог на radio.weblogs.com/0132036/.