|
| |||
Майк Лехманн Обеспечение безопасности Web-сервисов
Источник: журнал Oracle Magazine, no.1, 2005, http://www.oracle.com/technology/oramag/oracle/05-jan/o15web.html Обеспечение безопасности: от транспортных протоколов к сообщениям Когда я выступаю с презентациями по Web-сервисам, аудитория обязательно задает вопросы об обеспечении безопасности. Наиболее типичный вопрос таков: "Как вы обеспечиваете безопасность Web-сервисов?", за которым часто следует скептическое замечание: “Безопасность Web-сервисов нельзя обеспечить". Но, вспомните, большинство Web-сервисов в настоящее время основано на тех же самых основных технологиях, на которых основана сама Паутина (Web), а именно HTTP. Как результат, все те технологии, которые обеспечивают безопасность Web-приложений—базисная аутентификация (basic authentication) и SSL, они наиболее часто применимы, — в той же мере работают и c Web-сервисами. Эти технологии были чрезвычайно эффективны на протяжении ряда лет при использованиями со всевозможными онлайновыми бизнес-транзакциями, и они точно также работают и с Web-сервисами. Однако, главная проблема, с которой сталкиваются организации при попытке разработать подход обеспечения безопасности в среде Web, заключается в том, что такие типовые решения, как SSL, не совсем походят, так как они обеспечивают безопасность на уровне транспортного протокола, а не на уровне SOAP-сообщения, пересылаемого по этому протоколу. Более того, во многих интеграционных проектах, которые базируются на использовании сообщений, необходимы несколько промежуточных этапов, прежде чем сообщения прибудут в пункт назначения (target end point), и при обеспечении безопасности только на уровне транспортного протокола они остаются незащищенными в каждом промежуточном пункте назначения. Чтобы получить более детальный контроль над безопасностью и избежать проблем с ней на промежуточных этапах, организации, применяющие интеграцию на основе использования SOAP-сообщений, как правило, предпочитают обеспечение безопасности на уровне сообщений, а не на уровне транспортного протокола. А это означает, обеспечение безопасности собственно сообщений независимо от транспортного уровня. Несколько вопросов становятся очевидными при таком подходе. Во-первых, функциональность SSL, стандартно предоставляемая большинству Web-сервисов, заменяется тем, что я называю обеспечение безопасности сообщения (message security), необходимым для любых клиента и сервера, чтобы взаимодействовать с безопасным сообщением. Во-вторых, информация, связанная с обеспечением безопасности, передается в самом сообщении. В-третьих, если промежуточный или конечный пункты назначения (intermediary or end point) не обладает корректной инфраструктурой безопасности и не вызывает доверия, сообщение останется защищенным, безопасным и нечитаемым, и может быть передано дальше к следующему пункту назначению. Обеспечение безопасности Web-сервисов: WS-Security Так как же обеспечить безопасность именно на уровне сообщения, а не транспорта? Ответ заключается в использовании WS-Security, стандарта комитета OASIS, опубликованного как общепризнанная отраслью рекомендация в апреле 2004. WS-Security определяет механизм добавления трех уровней обеспечения безопасностей SOAP-сообщений. Токены аутентификации (Authentication Tokens): токены аутентификации WS-Security позволяют клиентам послать стандартизованным образом ‘имя пользователя’ (username) и ‘пароль’ (password) или сертификаты X.509 с целью аутентификации внутри заголовков (headers) SOAP-сообщений. Хотя токены SAML и Kerberos достаточно широко используются, профиль WS-Security для этих токенов еще не выпущен. Шифрование XML (XML Encryption): В WS-Security используется стандарт XML Encryption консорциума W3C, что обеспечивает шифрование тела (или его частей) SOAP-сообщения для гарантии его конфиденциальности. Как правило, поддерживаются различные алгоритмы шифрования — в Oracle Application Server 10g Release 10.1.3 поддерживаются алгоритмы 3DES, AES-128 и AES-256. Цифровые подписи в XML-документах (XML Digital Signatures): Использование стандарта XML Digital Signature консорциума W3C в WS-Security позволяет снабжать SOAP-сообщения цифровыми подписями для гарантии целостности сообщения. Как правило, эта подпись вычисляется на основе содержания самого сообщения: если сообщение изменено по дороге, цифровая подпись становится неверной. Oracle Application Server поддерживает алгоритмы DSA-SHA1, HMAC-SHA1, RSA-SHA1 и RSA-MD5. Конфигурирование Web-сервисов на стороне сервера Когда разработчики рассматривают три компонента WS-Security, естественно, они задают вопрос: как программным образом реализовать аутентификацию, шифрование и цифровые подписи в приложениях? Способ, который предлагают большинство поставщиков, например, Oracle, для реализации WS-Security - это декларативный механизм, который применяется как к новым, так и к уже существующим Web-сервисам. В продукте Oracle JDeveloper 10g Release 10.1.3, например, вы просто щелкаете (right-click) на кнопку (node) ) Web service, выбираете Secure Web Service, и далее идете, ведомые простым визардом. Рисунок 1 – это снимок экрана, представляющий как этот базовый набор средств для WS-Security выглядит в Oracle JDeveloper.
Рисунок 1: Обеспечение безопасности Web-сервиса в Oracle JDeveloper 10g Release 10.1.3 Чтобы показать простой пример WS-Security в действии, я воспользуюсь атрибутами аутентификации (authentication properties), представленными на Рисунке 1 — имя пользователя (username), токен аутентификации пароля (password authentication token) и более ничего — и применю их к Web-сервису HRService с методом getEmpSalary. После того, как я щелкну по кнопке OK в визарде обеспечения безопасности, сгенерируется файл специфичных для Oracle дескрипторов oracle-webservices.xml на Листинге 1 (показанный с определениями namespace, убранными для минимизации занятого места). Отметим, что возможности WS-Security времени выполнения (runtime) обеспечиваются элементом <runtime> и требованием к серверу аутентифицировать по имени пользователя (username) и паролю (password), определенных в элементе <verify-username-token>. Листинг 1: Конфигурация на сервере для WS-Security в oracle-webservices.xml. <oracle-webservices>
<webservice-description name="HRService">
<port-component name="HRServicePort">
<runtime enabled="security">
<security>
<inbound>
<verify-username-token password-type="Plain Text"
require-nonce="false"
require-created="false"/>
</inbound>
</security>
</runtime>
<operations>
<operation name="getEmpSalary"
input="{http://server.omag.com}getEmpSalaryElement"/>
</operations>
</port-component>
</webservice-description>
</oracle-webservices>
Как только эта конфигурация развернута в типовом для Web-сервисах файле ear (normal Web service ear file), это файл конфигурации wsmgmt .xml для управления на функционирующем (runtime side) Oracle Application Server, модифицируется этой информацией. Я проиллюстрировал этот процесс с помощью диаграммы в своей последней статье об управлении Web-сервисами. После развертывания Web-сервис готов для тестирования токеном WS-Security с именем пользователя и паролем (WS-Security username password token). Конфигурирование Web-сервисов на стороне клиента Следующий шаг заключается в том, как определить, каким образом этот токен WS-Security с именем пользователя и паролем, “вставить” в SOAP-сообщения со стороны клиента Web- сервиса. Как правило, в наборе инструментов для Web-сервисов для этого предлагается либо API, либо декларативный механизм.
Обеспечение безопасности Web-сервисов на уровне безопасности сообщений Из-за использования декларативного механизма реализации WS-Security, поддерживаемой в Oracle Application Server, важно уяснить, что как на стороне сервера, где расположен файл конфигурации, определяющий характеристики WS-Security, так и на стороне клиента необходимо “зеркало”, копия этой информации, чтобы во время выполнения на стороне клиента Web-сервисов можно было определить соответствующие установки обеспечения безопасности для их применения к выходящим (outbound requests) и входящим (inbound response) сообщениям. Для того, чтобы сконфигурировать эту информацию, Oracle JDeveloper предоставляет копию (mirror image) визарда, показанного на Рисунке 1 для Web-сервиса на стороне клиента. Основное отличие между двумя этими визардами заключается в том, что клиентский визард обеспечивает возможность поставки имени пользователя и пароля, а серверный визард - нет. На Листинге 2 представлена сгенерированная на стороне клиента конфигурация. С другой стороны, так как многие разработчики ленятся вводить такую информацию в конфигурационные файлы (хотя это полезно для тестирования), в Oracle Application Server предлагается простой API на стороне клиента, чтобы программно устанавливать токены имени пользователя и пароля на клиентской стороне Web-сервисов. Когда я выполнял сгенерированный файл на стороне клиента, было сгенерировано представленное на Листинге 3 сообщение, содержащее — помимо запроса зарплаты служащего — и токен с именем пользователя и паролем, внесенным в его заголовок и ссылки WS-Security на поддерживающие стандартные схемы со стандартными префиксом wsse пространства имен WS-Security. Вывод
Так же как и со многими другими стандартами WS-*, с WS-Security часто возникают опасения о взаимодействии (interoperability) в разнородной среде. В моем примере я выбрал простейший сценарий, но в реальной жизни с более сложными токенами аутентификации, шифрованием и цифровыми подписями эта проблема быстро становится очень сложной. Наша отрасль хорошо представляет эту проблему и нейтральные (относительно поставщиков) форумы, такие как Web Services Interoperability Organization (WS-I) уже начали работать над этим с участием основных поставщиков, включая Oracle, чтобы гарантировать взаимодействие, совместную работу реализаций WS-Security от Oracle, IBM, Microsoft, Sun и BEA. Что из этого появится? Профайл или набор рекомендованных лучших практик о том, как использовать WS-Security, называемый Basic Security Profile. Он будет дополняться другим ключевым профайлом, опубликованным комитетом WS-I, который называется Basic Profile 1.1 и фокусируется на лучших практиках с SOAP, UDDI и WSDL. В следующей статье я рассмотрю сертификаты X.509, цифровые подписи и шифрование с WS-Security.
Майк Лехманн (mike.lehmann@oracle.com) -- главный менеджер по продуктам в подразделении по Oracle Application Server Containers for J2EE.
Листинг 2: Конфигурация клиента для WS-Security
Листинг 3:
SOAP-сообщение от сервиса HRService с токеном, содержащим имя пользователя
|
