Разработка веб-служб средствами Java. Ильдар ХабибуллинРазработкаWebслужбсредствами
 Скачать 9.24 Mb.
|
|
id=""> [?] id=""> id=""> [*] Глава 7. Web Services как часть J2EE 327 id=""> id=""> id=""> [?] id=""> В листинге 7.9 приведен конфигурационный файл Web-службы "HelloService", построенной в листингах 7.3, 7.4, 7.7. * Листинг 7.9. Конфигурационный файл Web-службы "HelloService" version="1.0" PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN" HelloService 328 Разработка Web-служб средствами Java Конфигурационный файл клиента Второй конфигурационный файл с именем — это XML- файл с корневым элементом В него заносятся ссылки на другие Web-службы, чьими услугами пользуется данная Web-служба. В этой ситуации данная Web-служба является клиентом тех Web-служб, на которые делается ссылка. Отсюда происходит название файла и корневого элемента. Каждая ссылка описывается внутри элемента Глава 7. Web Services как часть J2EE 329 ся внутрь элемента в котором элементом отмечается имя компонента. Все остальные элементы вложены в элемент В элементе дается имя ссылке. Это имя используется клиентом при поиске Web-службы методом lookup () в системе именования JNDI. Рекомендуется начинать имя со строки "service/". В элементе обычно это интерфейс или его расширение. Остальные элементы, вложенные в элемент Элементы и указывают расположение WSDL-файла и JAX-RPC-файла в модуле. Элемент XML- элемента WSDL-файла, описывающего Web-службу. Он записывается толь- ко в том случае, когда в файле есть элемент Элемент связывает полное имя с именем определенным в элементе name> файла Эта связка используется затем контейнером при обращении клиента к методу getPort о для получения заглушки. Наконец, элементы описывают классы-обработчики SOAP- послания. Порт, к которому приписан обработчик, указывается вложенным элементом Если порт не указан, то обработчик приписывается ко всем портам. В листинге 7.10 приведена полная схема конфигурационного файла webservicesclient.xml. Листинг Структура конфигурационного файла клиента ; id=""> id=""> [+] Разработка Web-служб средствами Java id=""> [?] id=""> [?] id=""> id=""> id="">? id=""> id=""> id=""> [?] id=""> [?] id=""> [?] [?] id=""> id=""> id=""> id=""> Глава 7. Web Services как часть J2EE 331 id=""> [*] В листинге 7.11 приведен пример простого конфигурационного файла кли- ента Web-службы "HelloService", описанной в конфигурационном файле листинга 7.9. ' Листинг Конфигурационный файл клиента Web-службы "HelloService" version="1.0" encoding="UTF-8"?> PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services client 1.0//EN" Разработка Web-служб средствами Java Конфигурационный файл JAX-RPC У третьего конфигурационного файла, который мы назвали JAX-RPC- файлом, нет определенного имени, обычно его имя складывается из имени порта и слова "Mapping". Этот файл хранится в одном каталоге с WSDL- файлом, то есть, в каталоге WEB-INF или в каталоге META-INF. В самом простом случае, когда WSDL-файл описывает только один элемент с одним вложенным элементом . Элемент связывает пакет Java, указанный во вложенном элементе , с идентификатором пространства имен, опреде- ленным в WSDL-файле. Идентификатор указывается во вложенном элемен- те В остальных случаях в корневой элемент надо обяза- тельно вложить по одному элементу для каждого типа, введенного в WSDL-файле, по одному элементу для каждого WSDL-элемента и по одному элементу Кроме ТОГО, ВЛОЖИТЬ ПО ОДНОМУ Элементу < s e r v i c e - endpoint-interface-mapping> для каждой комбинации WSDL-элементов И В листинге 7.12 приведена полная схема конфигурационного JAX-RPC-файла. Листинг Структура конфигурационного файла id=""> [+] Глава 7. Web Services как часть 333 id=""> id=""> id=""> [*] id=""> id=""> id=""> [*] id=""> id=""> [?] id=""> [?] [+] id=""> [?] id=""> id=""> [*] id=""> id=""> 334 Разработка Web-служб средствами Java id=""> id=""> id=""> id=""> id=""> id=""> id=""> id=""> В листинге 7.13 приведен JAX-RPC-файл Web-службы "HelloService". Его имя HelloMapping.xml. Листинг Конфигурационный JAX-RPC-файл Web-службы "helloService" PUBLIC Глава 7. Web Services как часть J2EE 335 "-//IBM Corporation, Inc.//DTD J2EE JAX-RPC mapping 1.0//EN" ava-wsdl-mapping> hello Установка Web-службы в контейнер Поскольку по спецификации "Web Services for J2EE" Web-служба реализует- ся с помощью или session-компонентов, ее надо установить (deploy) в Web- или EJB-контейнер как всякий компонент J2EE- приложения. В процессе установки создаются клиентские заглушки и сер- верные связки системы RMI, каталоги для их размещения, пути к ним и переменные окружения, составляющие контекст приложения. Правила ус- тановки описаны, например, в книге [10]. Производители предоставляют утилиты установки, облегчающие этот процесс. В стандарт- ную поставку пакета J2EE SDK входит графическая утилита которая открывает последовательно несколько диалоговых окон, собирая сведения об устанавливаемом компоненте, и затем устанавливает компонент в контейнер. Утилита установки Web-службы, реализованной по правилам спецификации WS4EE, должна учитывать, что Web-служба работает под управлением ме- ханизма JAX-RPC, а не механизма RMI. Кроме того, в процессе установки надо создать или использовать несколько конфигурационных файлов: WSDL-файл, конфигурационный файл компонента или конфигурационный файл Web-службы конфигурационный файл клиента и JAX-RPC-файл. Поэтому для Web- службы надо использовать специализированные средства установки. Фирма IBM поставляет эталонную реализацию (RI — Reference Implementation) спецификации "Web Services for J2EE" со своего сайта http://www-106.ibm.com/developerworks/webservices/. В нее входят классы, полностью реализующие интерфейсы спецификации, вспомогательные классы и утилиты. Классы эталонной реализации расширяют пакет классов Разработка Web-служб средствами Java J2EE SDK, образующих J2EE-cepBep и используются Web-службами, уста- новленными на этом сервере. Для построения Web-службы эталонная реализация предлагает утилиту svcgen (Web Service Generator), работающую из командной строки. Ее мож- но использовать двумя способами: или для создания Web-службы по уже откомпилированным интерфейсам и классам, или для создания Web- службы по ее описанию В первом случае командная строка выглядит так: $ svcgen [ ] -sei \ -map -wsdl В этой строке необязательный параметр -classpath указывает путь к клас- сам Web-службы. Параметр -sei содержит краткое имя без расширения Параметр связывает идентификатор целевого про- странства имен создаваемого утилитой WSDL-файла с пакетом классов Java. Параметр -wsdl содержит имя создаваемого утилитой WSDL-файла. Во втором случае командная строка выглядит иначе: $ svcgen -wsdl -map [ - d i r ] Здесь параметр -wsdl содержит имя уже существующего WSDL-файла. Па- раметр определяет имя создаваемого пакета Java. Необязательный па- раметр -dir указывает имя каталога, в который будут помещены создавае- мые утилитой файлы Java и JAX-RPC-файл, имя которого повторяет имя WSDL-файла с окончанием Если этот параметр опущен, то файлы будут помещены в каталог Создан- ные файлы надо просмотреть, добавить в них фактический код Web-службы и откомпилировать. После создания Web-службы ее надо упаковать в архив application.ear обыч- ными средствами J2EE-cepBepa, например, утилитой При упа- ковке надо включить в архив файл а для клиента файл Это можно сделать впоследствии утилитой wsdd. Установка созданной и упакованной Web-службы выполняется утилитой Ее командная строка выглядит так: $ wsdepioy ] Первый параметр ГЛАВА 8 Безопасность предоставления услуг Сфера применения Web-служб стремительно расширяется. В настоящее время в нее вовлекаются банковские транзакции, финансовые операции, медицинские консультации — те Web-услуги, которые требуют секретности, точности, достоверности. Это заставляет обращать особенное внимание на безопасность предоставления услуг. Вопросы безопасности обсуждаются с тех самых пор, как люди стали пре- доставлять и получать услуги. При заключении всякой сделки важно убе- диться в том, что она будет совершена точно, в срок, с соблюдением всех оговоренных условий. Применительно к Web-услугам можно выделить пять основных проблем безопасности. • Конфиденциальность (confidentiality) данных. Сообщения, пересылаемые между Web-службой и ее клиентами, не должны читаться никем, кроме отправителя и получателя. Конфиденциальность достигается шифрова- нием сообщений. • Целостность (integrity) данных. Клиент и Web-служба должны быть уве- рены, что данные во время пересылки не изменились посторонними ли- цами или аппаратными средствами. Уверенность в целостности сообще- ния обеспечивается цифровой подписью или добавлением дайджеста со- общения (Message Digest). • Аутентификация (authentication) партнера или сообщения. И клиент, и Web-служба должны быть уверены, что имеют дело с тем партнером, за кого он себя выдает. Для этого сообщение подписывается цифровой подписью, известной другой стороне, или к сообщению прилагается цифровой сертификат. 12 748 338 Разработка Web-служб средствами Java • Авторизация (authorization) клиента. Клиент может получить только те услуги, которые он имеет право получать. Это достигается разными спо- собами: назначением ролей, составлением списков доступа ACL (Access Control Lists), выбором политики доступа. • Неаннулируемость (nonrepudiation) услуг. И клиент, и Web-служба долж- ны быть уверены, что другая сторона строго выполнит взятые на себя обязательства. Этого можно достигнуть при помощи цифровой подписи или Как видно из этого перечня, за многие века обмена услугами выработаны и методы решения проблем безопасности. Давно существует и бурно развива- ется целая наука — криптография. Приведем краткое описание ее основных Криптография Криптография занимается разработкой методов обработки данных с целью сокрытия их смысла. Для этого одним из множества алгоритмов шифрова- ния исходное сообщение преобразуется в бессмысленный набор битов, ко- торый можно быстро преобразовать обратно в первоначальный текст, толь- ко зная ключ (key) шифрования. Секретность ключа обеспечивает конфи- денциальность сообщения. Различают два вида ключей: симметричные (закрытые) ключи, и асиммет- ричные (открытый и закрытый) ключи. Симметричные ключи Шифрование и расшифровка сообщения производятся с помощью одного и того же ключа, поэтому он и называется симметричным ключом. Алго- ритмы шифрования с симметричным ключом работают быстро и надежно. Их надежность напрямую зависит от длины ключа — чем длиннее ключ, тем больше времени требует дешифровка сообщения. (Дешифровкой назы- вается попытка чтения зашифрованного сообщения без знания ключа.) Наиболее распространены следующие алгоритмы, применяющие симмет- ричные • Широко распространен алгоритм DES (Data Encryption Standard) с 56- разрядным ключом. Это стандарт для защиты от несанкционированного доступа к служебной документации в государственных учреждениях США. • В России для тех же целей применяется ГОСТ Он использует 256-разрядный ключ. Глава 8. Безопасность предоставления услуг 339 • Алгоритм DES часто применяется к сообщению трижды с разными клю- чами. Эта схема шифрования называется или 3DES. • Международный алгоритм шифрования данных IDEA (International Data Encryption Algorithm) использует 128-разрядный ключ. • Алгоритмы Брюса Шнайера (Bruce Schneier) с 56-разрядным ключом, и в котором длина ключа достигает 256 разрядов, не запатентованы и свободно доступны в Интернете по адресу • Широко распространена целая серия алгоритмов Рональда Ривеста (Ronald Rivest) RC2, RC4, RC5, RC6. Они различаются скоростью шиф- рования и длиной секретного ключа. Вся проблема заключается в передаче секретного ключа. Обеспечить ее конфиденциальность не менее важно и не менее трудно, чем обеспечить конфиденциальность самого сообщения. Очень часто эту проблему решают применением асимметричных ключей, при помощи которых передается секретный симметричный ключ. Асимметричные ключи В этом случае у каждого участника обмена сообщениями — Web-службы и ее клиента — есть по два ключа — открытый (public key), известный всем, и закрытый (private key), известный только самому участнику. Открытый ключ предназначен для шифрования сообщения, закрытый — для рас- шифровки. Клиент шифрует свое сообщение открытым ключом Web- службы и посылает шифровку вместе со своим открытым ключом. Зашиф- рованное сообщение может прочитать только Web-служба, которой оно предназначено. Web-служба расшифровывает его своим закрытым ключом, читает, составляет ответ, и шифрует ответное сообщение открытым ключом клиента. Зашифрованный ответ может прочитать только клиент, расшифро- вав его своим закрытым ключом. Итак, при использовании асимметричных ключей вместе с зашифрованным сообщением или до посылается открытый ключ отправителя. Разработано множество алгоритмов шифрования с асимметричными ключами. • Алгоритм DSA (Digital Signature Algorithm) позволяет использовать ключи любого размера. Алгоритм стандартизирован, стандарт DSS (Digital Signature Standard) рекомендует ключи длиной от 512 до 1024 двоичных разрядов. Алгоритм применяется, главным образом, для создания циф- ровой • Алгоритм RSA, названный по первым буквам фамилий авторов (Rivest, Shamir, Adleman), использует ключи длиной до 1024 битов. 340 Разработка Web-служб средствами Java • Алгоритм Диффи-Хелмана DH работает с ключами дли- ной до 4096 битов. • Алгоритм Тегера Эль-Гамала (Taher не запатентован, он используется свободно. В реальных криптографических системах симметричные и асимметричные ключи часто комбинируются. Например, известно, что шифрование откры- тым ключом занимает больше времени, чем шифрование секретным клю- чом. Для ускорения работы поступают так: сообщение шифруют симмет- ричным ключом, затем этот симметричный ключ шифруют открытым клю- чом получателя и отправляют вместе с зашифрованным сообщением. Получатель сначала расшифровывает симметричный ключ своим закрытым ключом, а затем расшифровывает сообщение уже известным ему симмет- ричным Дайджест сообщения Иногда в результате шифрования получают короткий дайджест сообщения MD (Message Digest), который посылают вместе с незашифрованным сооб- щением. Это делается не с целью достижения конфиденциальности, а для сохранения целостности послания. Получатель повторно шифрует сообще- ние тем же алгоритмом и сравнивает полученный дайджест с тем, который был прислан вместе с сообщением. Совпадение дайджестов гарантирует не- изменность сообщения по пути следования. Своеобразие дайджеста заклю- чается в том, что его не надо расшифровывать. Это позволяет применять для получения дайджеста мощные односторонние алгоритмы. • В настоящее время наибольшее распространение получил алгоритм Ро- нальда Ривеста MD5, описанный в рекомендации RFC 1321. Он создает 128-разрядный дайджест. • Алгоритм (Secure Hash Algorithm) использует хеш-функцию для получения 160-разрядного дайджеста. У алгоритма есть расширения SHA-256, SHA-384, для получения более длинных дайджестов. • В алгоритмах под общим названием MAC (Message Authentication Code) кроме самого алгоритма используется и секретный ключ. Алгоритм ис- пользуется главным образом для создания цифровой подписи. Цифровая подпись Для решения задач аутентификации и неаннулируемости, сообщение часто снабжается цифровой подписью. В самом простом случае для получения цифровой подписи применяются асимметричные ключи обратным спосо- Глава 8. Безопасность предоставления услуг 341 бом — автор сообщения шифрует его своим закрытым, а не открытым клю- чом. После этого всякий желающий может расшифровать сообщение от- крытым ключом автора и прочитать его. Поскольку закрытый ключ знает только автор, зашифровать сообщение мог только он. Этим подтверждается авторство сообщения. Зашифровать сообщение можно и симметричным ключом, но потом его придется открыть для проверки авторства. Такой ключ будет одноразовым, для следующего сообщения придется генерировать другой ключ. В других случаях в качестве цифровой подписи используется дайджест со- общения, зашифрованный с помощью закрытого ключа автора. Адресат может получить тот же дайджест, используя открытый ключ автора сообще- ния, сравнить его с дайджестом самого сообщения и убедиться в авторстве сообщения. Цифровой сертификат Широкое распространение открытых ключей поставило задачу целостности и аутентификации самих открытых ключей. Отправитель, шифрующий со- общение открытым ключом адресата, должен быть уверен, что ключ дейст- вительно принадлежит адресату, а не подменен злоумышленником, высту- пающим от имени адресата. Для этого открытые ключи заверяются цифро- вой подписью, но подписью не адресата, а доверенного лица — центра сертификации СА (Certificate Кроме открытого ключа и цифровой подписи, сертификат содержит сведе- ния о центре сертификации и пользователе ключа, время действия ключа, назначение ключа: шифрование, цифровая подпись, дайджест. Структура сертификата и правила его использования определены международным стандартом ISO X.509. Центры сертификации имеются во многих странах. Наиболее авторитетна организация VeriSign, у которой есть сеть филиалов на нескольких сайтах Интернета. Реализация криптографии в Java В стандартную поставку Java 2 SDK, Standard Edition входят средства Security API, реализующие многие криптографические алгоритмы. В Security API вхо- дит пакет JCA (Java Cryptography Architecture) и дополнение к нему — пакет JCE (Java Cryptography Extension). Эти пакеты составлены из пакетов Java java. security, crypto и их подпакетов, а также пакета и его подпакетов, содержащих средства генерации ключей, шифрования, создания дайджестов и цифровых подписей. Кроме того, 342 Разработка Web-служб средствами Java в Security API входит пакет и его подпакеты, содержа- щие средства аутентификации и авторизации и составляющие, вместе с дру- гими пакетами Java, пакет JAAS (Java Authentication and Authorization Service). Классы, составляющие средства Security API, реализуют криптографические алгоритмы DES, IDEA, DSA, MD5, RSA и другие, создают серти- фикаты по протоколу Х.509, связывают приложения Java с системой безо- пасности Kerberos. Мы не будем здесь рассматривать Security API. Средства этого пакета подробно описаны в книге [13] и множестве других книг, посвященных безопасности Java. Текущая версия Security API полностью описана в документации к вашему набору J2SE SDK, в разделе $JAVA_HOME/docs/guide/security/. Безопасность на транспортном уровне Сообщения Web-службы передаются по компьютерным сетям. Поэтому, казалось бы, для безопасности их пересылки достаточно применить средст- ва сетевой безопасности. Одно из таких средств — протокол защищенных соединений SSL (Secure Sockets Layer), запатентованный в США фирмой Netscape Communication. Протокол работает поверх стека TCP/IP и основан на шифровании содержимого сетевых IP-пакетов с помощью симметричных или асимметричных ключей. Он описывает правила установления соедине- ния, открытия защищенных сокетов, обмена ключами, шифрования и пере- дачи данных. С ним тесно связан основанный на версии SSL 3.0 открытый протокол TLS (Transport Layer Secure), первая версия которого определена в рекомендации RFC 2246. Протокол TLS очень похож на SSL и призван за- менить его, но эти протоколы несовместимы. Протоколы SSL и TLS могут применять разные алгоритмы шифрования, в том числе DES, RSA, SHA-1, MD5, RC2, RC4. Это позволяет найти общий алгоритм для клиента и сервера и практически всегда установить защищен- ное соединение. При этом алгоритмы шифрования с асимметричными клю- чами применяются при установлении связи и передаче сгенерированного секретного ключа, а алгоритмы с симметричными ключами — для пересыл- ки сообщений, зашифрованных полученным секретным ключом. Технология Java реализовала протоколы SSL 3.0 и TLS в пакете JSSE (Java Secure Socket Extension). Соответствующие пакеты Java входят в стандартную поставку J2SE SDK. Они под- робно описаны в книге [13] и в документации J2SE SDK. Средства SSL и TLS удобны и хорошо обеспечивают конфиденциальность передаваемых данных, но у них нет собственных средств аутентификации. Они должны получать сертификаты из какого-нибудь центра сертификации. Глава 8, Безопасность предоставления услуг 343 Другое сетевое средство безопасности — виртуальная частная сеть VPN (Virtual Private Network) — не требует сертификатов. Оно передает сообще- ния, зашифрованные на выходе из локальной сети маршрутизаторами или брандмауэрами. Аутентификация сообщений и клиентов производится маршрутизаторами или брандмауэрами на входе в локальную сеть. Вирту- альные частные сети требуют установки программного обеспечения на каж- дый сервер, маршрутизатор, брандмауэр и на каждую клиентскую машину, что вызывает обычные проблемы совместимости версий и необходимости их обновления на каждой машине. Виртуальная частная сеть создается, чаще всего, на основе стандартов сете- вого уровня IPv6 или на основе протокола РРТР (Point-to-Point Tunneling Protocol). Средства сетевой безопасности транспортного уровня могут использоваться при организации защищенных Web-служб, но сильно ограничивают их применение. Во-первых, эти средства привязывают Web-службу к опреде- ленному протоколу: HTTPS, SMTP, хотя основное достоинство Web- службы — ее переносимость и независимость от протоколов и платформы. Во-вторых, эти средства шифруют все пересылаемое сообщение целиком, а SOAP-послания по пути следования могут обрабатываться промежуточными SOAP-узлами (actors). При этом промежуточный сервер должен расшифровать послание, обработать его и снова зашифровать для дальней- шей пересылки. Ясно, что после этого ни о какой секретности говорить не приходится. Безопасность на уровне XML Для того чтобы зашифровать не всё SOAP-послание, а только его отдельные части, придется перейти на уровень языка XML и пойти привычным пу- тем — ввести дополнительные элементы XML, описывающие зашифрован- ную часть послания. Разработка средств описания зашифрованных XML-документов и их от- дельных частей ведется консорциумом W3C давно и независимо от прото- кола SOAP и Web-служб, причем этим занимается сразу несколько рабочих групп. • Рабочая группа, определяющая правила описания шифрования документов выпустила предварительную версию рекомендации "XML Encryption Syntax and Processing". Будем называть ее короче "XML Encryption". Ее можно посмотреть по адресу • Рабочая группа, разрабатывающая правила работы с цифровыми подпи- сями на языке XML, ее сайт пред- ложила две рекомендации: RFC 3275 описывает синтаксис цифровой Разработка Web-служб средствами Java подписи, a RFC 3076 — так называемую каноническую форму XML (Canonical XML). • Третья рабочая группа рассматривает работу с цифровыми сертифика- тами и разрабатывает правила обмена ключами шифрования. Она разработала спецификацию (XML Key Management Specification) и работает над ее второй версией. Ее можно посмотреть на сайте Рассмотрим подробнее эти рекомендации и спецификации. Шифрование документов Документы XML или их отдельные элементы шифруются с использованием обычных алгоритмов криптографии. Задача состоит в том, чтобы выделить зашифрованную часть документа и описать способ ее шифрования. Рекомендация "XML Encryption" вводит новый XML-элемент и вложенные в него элементы. Все элементы определены в пространстве имен с идентификатором Они описывают метод шифрования, сам зашифрованный элемент и тому подобную информацию. При помощи элемента Допустим, что в некотором XML-документе есть элементы и нам надо зашифровать элемент содержащий секретный номер абонента. Это можно сделать двумя способами. Первый способ — зашифровать только содержимое элемента: Второй способ — зашифровать весь элемент Глава 8. Безопасность предоставления услуг 345 <!— вложенные элементы с зашифрованным элементом —> Обратите внимание на то, как изменился атрибут — вместо заключи- тельного указания "content" атрибут содержит слово "Element". Вообще же у элемента • атрибут содержит идентификатор элемента • атрибут туре содержит тип зашифрованной информации в виде стро- ки URI; • атрибут указывает зашифрованной информации обычной строкой или строкой URI; • атрибут Encoding указывает кодировку содержимого в виде строки URI. Остальные атрибуты описывают идентификаторы пространств имен; очень часто они выглядят так: • Элемент ШИфрО- вания своим обязательным атрибутом Algorithm. В этот элемент можно вложить элемент и другие элементы, например, для записи параметров алгоритма RSA- ОАЕР специально предназначен вложенный элемент Элемент можно опустить, если алгоритм шифрова- ния был оговорен заранее. • Элемент описывает применяемые ключи шифрования. Как видно из его префикса, он определен в пространстве имен с иден- тификатором Это пространство имен цифровой подписи, оно описано в следующем разделе. Дополнительно в этот элемент можно вложить элемент • Элемент 346 Разработка Web-служб средствами Java • Элемент ЦИЮ ВО В него элементах Из этих элементов обязателен только элемент во вложенном в него элементе содержится зашифрованная информация. Это двоичная информация, но она записывается в кодировке Base64. Таким образом, минимальный состав элемента Вместо элемента В элемент один или несколько элементов описывающих методы дополнительного преобразования извлеченной по ссылке зашифрованной информации. Например, извлеченную зашифрованную информацию можно переслать в кодировке Base64, для этого надо записать такое пре- образование: Глава 8. Безопасность предоставления услуг 347 Структура элемента повторяет структуру элемента В элементы и/или элементы своим атрибутом указывают идентификаторы (значения атрибутов элементов, использующих описы- ваемый зашифрованный ключ. Элемент Факт пересылки ключа отмечается вложенным элементом Полная схема вложенности элементов показана в листинге 8.1. - Листинг 8.1. Вложенность элементов шифрования [?] Algorithm=""> [?] [?] (? ] Algorithm=""> [?] 348 Разработка Web-служб средствами Java Algorithm=""> [?] [?] [?] [?] Глава 8. Безопасность предоставления услуг 349 Цифровая подпись документа XML Правила создания цифровой подписи документа XML определены в реко- мендации RFC 3275. Суть рекомендации в том, что создаются дайджесты подписываемой информации, они вкладываются в элемент вместе с нужными пояснениями. Затем создается дайджест этого элемента, который подписывается цифровой подписью. Элемент опре- делен в спецификации RFC 3275. Все это вкладывается в корневой элемент цифровой подписи тоже определенный в рекомендации RFC 3275. Непосредственно в элемент а также необязательный элемент и нуль или несколько элементов 350 Разработка Web-служб средствами Java Элемент может появиться несколько раз, поскольку подписы- ваемая информация может состоять из нескольких документов XML, доку- ментов HTML или их частей, файлов с графическими изображениями, зву- ковых файлов и других ресурсов. Каждый ресурс, которым может быть и часть документа, описывается своим элементом По- лученная цифровая подпись (detached signature) хранится отдельно от под- писанного документа. Цифровая подпись может быть вложена в сам подписываемый документ (enveloped signature). В этом случае ссылка будет выглядеть так: Каждый элемент преобразование к каноническому виду Кроме того, элемент Algorithm= /> Здесь для получения дайджеста файла выбран алгоритм SHA-1. Файл sign.xml предварительно приводится к каноническому виду XML. Элемент содержит цифровую подпись в кодировке Base64. Элемент описывает информацию об открытом ключе, с помощью которого проверяется подпись. Ключом может быть и цифровой сертифи- кат. Элемент может отсутствовать, если получателю известен ключ. Информация содержится во вложенных элементах, некоторые эле- менты определены спецификацией. Это элементы , ры цифровых подписей могут добавить другие элементы. Глава 8. Безопасность предоставления услуг 351 Элементы 352 Разработка Web-служб средствами Java Канонический вид XML При создании цифровой подписи имеет значение каждый символ подписы- ваемого документа. Даже разное количество пробелов между словами при- ведет к разным цифровым подписям. Для того чтобы цифровая подпись зависела только от содержания документа, но не от его оформления, доку- мент сначала приводится к каноническому виду, а потом подписывается. Метод приведения к каноническому виду указывается атрибутом элемента Канонический вид документа XML и правила приведения к нему описаны в рекомендации RFC 3076, называемой "Canonical XML". По рекомендации RFC 3076 документ записывается в кодировке UTF-8, все ссылки разреша- ются, пробельные символы нормализуются, заголовки XML удаляются, пус- тые элементы записываются парой из открывающего и закрывающего тега, записываются значения по умолчанию всех опущенных атрибутов и так да- лее. Если приведение к каноническому виду выполнено по этой рекоменда- ции, то элемент должен выглядеть так: Средства Java для шифрования XML Фирма IBM выпустила пакет интерфейсов и классов XSS4J (XML Security Suite for Java), реализующих спецификацию "XML Encryption", рекоменда- ции RFC 3275, RFC 3076, методы авторизации и получения сертификатов, методы приведения к каноническому виду. Пакет XSS4J можно свободно скопировать, он доступен по адресу Глава 8. Безопасность предоставления услуг 353 Для применения классов и интерфейсов пакета XSS4J достаточно добавить полученный при копировании архив xss4j.jar в библиотеку классов J2SE SDK, например, в каталог или добавить путь к архиву в переменную Пакет XSS4J требует для своей работы на- личия стандартного Java Security API, входящего в состав J2SE SDK. Кроме того, нужен XML-анализатор, например, Apache Xerces2, и XSLT- процессор, например, Apache Пакет XSS4J входит в состав не раз упоминавшегося в этой книге набора IBM WSTK и в состав интегрирован- ной среды разработки IBM WebSphere Studio. Сообщество Apache Software Foundation выпустило пакет "Apache XML Security", доступный адресу В него входят средства шифрования, реализующие спецификацию "XML Encryption", и средства создания цифровой подписи по рекомендациям RFC 3275 и RFC 3076. Пакет можно использовать отдельно или в составе других инст- рументальных средств XML. Он входит, например, в набор средств создания Web-служб Apache Axis, рассмотренный нами в главе 3. В листинге 8.3 показан пример клиента Web-службы, создающего SOAP- послание, подписывающего его цифровой подписью, отправляющего под- писанное послание Web-службе, и ожидающего от нее ответа. Перед тем как запустить клиентскую программу следует сгенерировать клю- чи и сертификат и записать их в стандартное хранилище ключей Java — файл Это можно сделать утилитой из набора J2SE SDK, набрав следующую командную строку: keytool -genkey и ответив на вопросы утилиты. : Листинг 8.3. Клиент Web-службы, отправляющий подписанное SOAP-послание import import import import import import import import import org.w3c.dom.*; import import j 354 Разработка Web-служб средствами Java import import public class ClientAxis{ static SOAPEnvelope env = new public static void args){ if != 3){ ClientAxis" + " " + " try{ Options opts = new Service service = new Service (); Call call = new j ) sbe = new "http://localhost:8080/EchoService", "")); args[l], " ) ; = Глава 8. Безопасность предоставления услуг 355 " ) ; e) { e.printStackTrace (); private static void String String try{ "SOAP-SEC")); "actor", "1"); SOAPHeaderElement header = new "http://schemas.xmlsoap.org/soap/security/2000-12", "Signature", "")); Document doc = soap2dom(env); KeyStore ks = fis new ; ks.load(fis, PrivateKey privateKey = Разработка Web-служб средствами Java Element soapHeaderElement = Element = sig = new X509Certificate cert = Canonicalizer cl4n canonicalMessage = InputSource is new new dser = null; AxisClient new Глава 8. Безопасность предоставления услуг 357 = new = new msgContext, e) { ; throw new private static Document soap2dom(S0APEnvelope env) throws writer = new ctx = new Reader reader = new Document doc = if (doc == null) throw new return doc; Существует еще много коммерческих и свободно распространяемых средств шифрования документов XML. Каждый месяц появляются новые средства, их списки можно просмотреть на сайтах Интернета, посвященных XML. Безопасность SOAP-посланий Поскольку SOAP-послание представляет собой документ XML, к нему при- менимы все средства обеспечения безопасности, перечисленные в преды- 358 Разработка Web-служб средствами Java дущих разделах этой главы. Ничто не мешает зашифровать все послание целиком или его отдельные части, например, тело послания, или отдельные элементы XML, входящие в послание. SOAP-послание можно снабдить цифровой подписью как обычный документ XML. Тем не менее, SOAP-послания следует составлять так, чтобы их могла про- читать и обработать любая Web-служба, имеющая право на это. Поэтому необходимы правила шифрования и подписи SOAP-посланий, единые для всех Web-служб. Такие правила разрабатываются как расширения протокола SOAP. Первое расширение протокола SOAP, посвященное вопросам безопасно- сти, было сделано фирмой IBM еще в 2000 году. Документ под названием "SOAP Security Extensions" опубликован в Интернете по адресу Он посвящен шифро- ванию, цифровой подписи и авторизации и вводит три соответствующих элемента XML Эти элементы записываются как блоки заголовка |