Web-сервисы Java: Ситуация в сфере безопасности Web-сервисов

О текущей ситуации в сфере обработки функций безопасности основными стеками Web-сервисов Java с открытым исходным кодом

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

Денис Сосноски, консультант, Sosnoski Software Solutions, Inc.

Денис Сосноски (Dennis Sosnoski) - основатель и ведущий специалист консалтинговой компании по технологиям Java - Sosnoski Software Solutions, Inc., специализирующейся в обучении и консультировании по проблемам XML и Web-сервисов. Он имеет более чем 30-летний опыт работы в профессиональном проектировании ПО, специализируясь на серверных XML и Java-технологиях. Денис является основным разработчиком интегрированной системы с открытым программным кодом JiBX XML Data Binding, построенной на базе технологии классов Java и связанной системы Web-сервисов JibxSoap, также как и системы Web-сервисов Apache Axis2. Он также был одним их экспертов при разработке спецификаций JAX-WS 2.0.



26.03.2012

Все основные стеки Web-сервисов обеспечивают определенный уровень поддержки WS-Security и соответствующих стандартов безопасности Web-сервисов. Все три стека с открытым исходным кодом, которые мы рассмотрели в этом цикле статей - Apache Axis2, Sun/Oracle Metro и Apache CXF - обеспечивают достаточно высокий уровень поддержки этих стандартов. Но во многих отношениях эта поддержка существенно различается, в частности, в отношении реализации защиты и настройки параметров безопасности в этих стеках.

Об этом цикле статей

Web-сервисы ― важная функция технологии Java в корпоративных вычислениях. В этом цикле статей консультант по XML и Web-сервисам Денис Сосноски рассказывает об основных структурах и технологиях, ценных для Java-разработчиков, использующих Web-сервисы. Следите за статьями цикла, чтобы быть в курсе последних разработок в данной области и знать, как применять их в своих собственных проектах.

Одно из важных различий относится к полноте и правильности реализации функций безопасности. WS-Security и WS-SecurityPolicy допускают много вариантов конфигурации параметров безопасности, в том числе различные типы ключей и сертификатов, наборы алгоритмов, токены и спецификации подписания/шифрования документов. WS-Trust и WS-SecureConversation еще больше увеличивают число вариантов. При таком количестве возможных конфигураций ни один стек Web-сервисов не сможет проконтролировать их все. Даже отдельная проверка значений каждого возможного варианта достаточно сложна, и большинство стеков не берется за эту задачу.

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

Взаимодействие в области безопасности

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

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

Некоторые усилия по улучшению качества кода безопасности Web-сервисов предпринимались, включая работу по проверке совместимости, выполненную отраслевой организацией и поставщиками. Последнее, в частности, помогло установить базовый уровень совместимости между стеками, но результаты оказались ограниченными ввиду небольшого числа проверенных конфигураций.

WS-I Basic Security Profile

Спецификации Web-сервисов SOAP с самого начала предлагали множество вариантов выбора для разработчиков и пользователей. Отчасти это определялось принятым подходом к проектированию. В других случаях это связано с упущениями в стандартах: ожидаемое поведение изложено недостаточно подробно, и разработчикам приходится гадать, что же нужно сделать. Проблема слишком большого числа вариантов заключается в том, что разработчикам не хватает ресурсов, чтобы проверить все возможные комбинации в полном объеме, поэтому некоторые варианты стеки Web-сервисов поддерживают хорошо, другие плохо, а третьи вовсе не поддерживают. Эта ситуация создает серьезные проблемы совместимости, так как нет никакой гарантии, что различные стеки поддерживают одни и те же варианты.

В первые годы SOAP чрезмерный выбор стал такой проблемой, что была создана специальная отраслевая группа с целью ограничения числа возможных конфигураций путем публикации "практических рекомендаций". Эта группа, Web Services Interoperability Organization (WS-I), подготовила ряд профилей, предписывающих выбирать или исключать те или иные варианты (см. раздел Ресурсы). Благодаря этим профилям WS-I оказала большое влияние на формирование текущего третьего поколения стеков Web-сервисов.

Безопасность является одной из областей, которые WS-I охватила в своих профилях. WS-I Basic Security Profile версии 1.1 (BSP 1.1) представляет собой текущий основополагающий документ в сфере безопасности. Этот документ включает в себя широкий спектр требований, но в большинстве своем эти требования относится к реализации стека Web-сервисов, а не к конфигурациям безопасности для конечных пользователей. BSP 1.1 не затрагивает конфигурацию WS-Security в WS-SecurityPolicy, хотя некоторые его требования могут быть переведены в термины WS-SecurityPolicy.

При использовании цифровой подписи BSP 1.1 предписывает следовать рекомендации W3C Exclusive Canonicalization, алгоритму канонизации XML, который игнорирует комментарии и ненужную информацию контекста (см. раздел Ресурсы). WS-SecurityPolicy использует этот алгоритм по умолчанию в отсутствие какого-либо выбора, так что все, что нужно сделать, чтобы выполнить это требование, ― не указывать другой алгоритм канонизации (например, <sp:InclusiveC14N>).

BSP 1.1 добавляет также некоторые другие требования, относящиеся как к подписям, так и к шифрованию, которые ограничивают набор алгоритмов, определенный в WS-SecurityProfile, но, по существу, оставляет выбор из алгоритмов шифрования TripleDES, AES128 или AES256 и дайджест-алгоритма SHA1 (исключая лишь варианты алгоритма шифрования AES192 и дайджест-алгоритма SHA256, предлагаемые WS-SecurityPolicy). Другие рекомендации BSP ограничивают то, как следует указывать и использовать различные токены безопасности.

WS-I BSP, несомненно, способствовал взаимодействию между реализациями Web-сервисов безопасности, но кроме указанных мелочей, он никак не облегчает выбор варианта конфигурации безопасности. Для внедрения практических рекомендаций по обеспечению безопасности с использованием современных конфигураций на основе политик была бы очень полезна новая версия BSP, больше ориентированная на конфигурации WS-SecurityPolicy, но WS-I, к сожалению, не проявляет заинтересованности в таком обновлении.

Испытания на совместимость

Испытания на совместимость между стеками, организованные поставщиками, сыграли более значительную роль в повышении качества реализации защиты в Web-сервисах. Движущей силой в этой области стала Microsoft®, которая провела в своем кампусе серию мероприятий Interoperability Plug-Fest, в рамках которых разработчики других стеков Web-сервисов (как коммерческих, так и с открытым исходным кодом) приглашались к участию в тестировании различных сценариев взаимодействия своего кода с реализацией Microsoft (см. раздел Ресурсы). Безопасность была одной из основных тем этих мероприятий.

Такое тестирование помогло установить базовый уровень совместимости между стеками, но результаты оказались ограниченными ввиду небольшого числа проверенных конфигураций. Акцент делался на взаимодействие с реализацией Microsoft (а не на соответствие действующим стандартам), что тоже служило ограничением, хотя с практической точки зрения это намного проще полной проверки совместимости между десятком или более стеков.


Проблемы и ограничения в сфере безопасности

В этом цикле статей я испытывал различные конфигурации безопасности трех стеков Web-сервисов и выявил несколько проблем в каждом из них. Ограниченное тестирование на взаимодействие (с использованием одного стека для клиента, а другого для сервера, и только для политики WS-SecureConversation) выявило еще больше проблем. В случае стека Apache Axis2 я обнаружил также серьезные проблемы производительности. Все эти проблемы были доведены до сведения разработчиков каждого стека, и в последних версиях некоторые из них исправлены. В этом разделе я кратко опишу текущее состояние трех стеков по результатам испытаний, которые я проводил для этих статей.

Проблемы Axis2

В число проблем, которые я обнаружил в Axis2, входит обработка политики WS-SecureConversation, тогда как определение bootstrap-политики в процессе работы, похоже, полностью игнорируется. Это означает, что Axis2 использует готовую конфигурацию для поддержки WS-SecureConversation, так что он совместим только с другими стеками, использующими ту же конфигурацию.

Что касается обработки функций безопасности во время выполнения, то серьезная проблема Axis2 связана с обработкой симметричных привязок на стороне клиента (как описано в статье WS-Security без клиентских сертификатов). С ростом количества запросов клиент работает все медленнее. Ввиду прогрессивного характера этой проблемы я полагаю, что это не проблема производительности, а явная ошибка.

Обработка запросов безопасности в Axis2 страдает также от устойчиво медленной работы при использовании функций безопасности (некоторые результаты см. в статье Производительность WS-SecureConversation). Эта проблема производительности, похоже, коренится в несовместимости объектной модели AXIOM, используемой Axis2, и стандартной DOM, используемой кодом безопасности, так что она, вероятно, сохранится до тех пор, пока AXIOM не будет расширена для достижения полной совместимости с DOM.

Наконец, на мой взгляд, Axis2 страдает от несоответствия между основным механизмом Web-сервисов (собственно код Axis2) и кодом безопасности (модули безопасности Rampart и Rahas). Ранее мы (коммиттеры Axis2) решили отделить код безопасности от кода ядра, чтобы эти компоненты можно было совершенствовать и выпускать по отдельности. К сожалению, это привело к тому, что код безопасности рассматривается в качестве дополнительного компонента, и были выпущены версии Axis2, которые не работали с тогдашней версией Rampart. Примером служит недавний выпуск Axis2 1.5.2: В двоичном дистрибутиве отсутствует JAR-файл, необходимый для обработки функций безопасности, так что его не просто заставить работать с Rampart. Эта проблема решена в текущей версии Axis2 1.5.3, но сам факт, что официальный выпуск может выйти без работающей поддержки функций безопасности, служит доказательством несоответствия.

Ни одна из серьезных проблем Axis2, которые я обнаружил при написании этих статей, в последних версиях Axis2 и Rampart не исправлена.

Проблемы Metro

Тесты, выполненные для статей этого цикла, выявили также некоторые существенные проблемы Metro. Главная проблема заключается в том, как Metro выполняет подписание тела сообщения. Если политика содержит утверждение <sp:OnlySignEntireHeadersAndBody/>, то все хорошо, но если это утверждение не используется, Metro снабжает подписью содержание тела сообщения, а не сам элемент body. Стеки, которые обрабатывают подписание правильно, будут отвергать сообщения, подписанные Metro таким образом.

Metro нарушает также политику WS-SecureConversation, которая использовалась в статье WS-Trust и WS-SecureConversation. Проблема в данном случае заключалась в том, что политика использует различные наборы алгоритмов для обмена bootstrap-сообщениями с Security Token Service (STS) и для фактического сообщения с сервисом. Metro игнорирует это и просто использует в обоих случаях один и тот же набор алгоритмов. Это не столь значительная проблема, как проблема с подписанием, так как на практике нет особых причин использовать два разных набора алгоритмов; тем не менее, это ошибка.

Наконец, в Metro есть проблемы, связанные с использованием одностороннего шифрования или подписания, описанные в статье Освоение WS-Policy. В последней версии Metro ни одна из этих ошибок не исправлена.

Проблемы CXF

При тестировании CXF для этих статей я нашел в нем несколько проблем, как и в других стеках. Почти все эти проблемы исправлены в новой версии CXF, вышедшей перед публикацией статьи. Единственным исключением стала проблема, связанная с использованием одностороннего шифрования или подписи, о которой говорилось в статье Освоение WS-Policy, ― она не исправлена в версии CXF 2.3.1.


Сравнение стеков

Любая попытка ранжировать стеки Web-сервисов по уровню поддержки ими функций безопасности неизбежно будет в высшей степени субъективной, так как каждый стек имеет как сильные и слабые стороны. Пытаясь дать взвешенную оценку, я разбил рейтинг на четыре фактора и присвоил им численное значение по классической 10-балльной шкале (чем выше балл, тем лучше) для каждого стека.

  • Корректность: сколько ошибок реализации известно, и насколько эти ошибки серьезны?
  • Полнота: насколько полна реализация функций безопасности?
  • Производительность: какую нагрузку добавляет обработка функций безопасности?
  • Юзабилити: насколько легко настроить функции безопасности?

Корректность

В Axis2 присутствует ряд серьезных проблем, и вызывает озабоченность разрыв между кодом ядра и модулем безопасности Rampart, но в целом этот стек кажется достаточно надежным. Оценка: Axis2 - 6

Metro имеет ряд существенных проблем, в частности, неправильно обрабатывает подписи, если не используется утверждение <sp:OnlySignEntireHeadersAndBody/>. Однако, как и Axis2, в целом этот стек кажется достаточно надежным, и интеграция кода безопасности в основную версию делает полный отказ менее вероятным, чем в случае Axis2. Оценка: Metro – 7.

CXF имеет лишь относительно незначительные известные проблемы и быстро реагирует на их обнаружение, а короткий цикл выпусков означает, что проблемы устраняются, как только они обнаружены. Оценка: CXF – 8.

Надо отметить, что я рассматривал только те проблемы, которые возникали непосредственно в ходе подготовки этих статей. Проверка стеков с помощью систем выявления ошибок покажет другие, потенциально более значимые, проблемы. В этом отношении следует проявлять осторожность - некоторые проблемы могут быть вызваны ошибками пользователя, - тем не менее, это полезное упражнение, если в организации планируется стандартизовать тот или иной стек. Информация о системах выявления ошибок для каждого из трех стеков приведена в разделе Ресурсы.

Полнота

Все три стека обеспечивают поддержку всех основных стандартов безопасности. Тем не менее, в Axis2 эта поддержка ограничена, по крайней мере, в двух отношениях. Для WS-Policy генерация кода Axis2 работает только с устаревшей версией submission 2004 года, но не со стандартной версией W3C, вышедшей в 2007 году. Для WS-SecureConversation Axis2 реализует "готовую" конфигурацию, игнорируя любую указанную ему конфигурацию политики. Оценки: Axis2 – 6; Metro – 7; CXF – 7.

Производительность

В любых рейтингах производительности при обработке функций безопасности Axis2 явно проигрывает. В каждой форме обработки функций безопасности на уровне сообщений он создает гораздо большую нагрузку, чем Metro или CXF. В целом Metro работает немного быстрее, чем CXF, так что мои оценки по данному фактору: Axis2 – 4; Metro – 8; CXF – 7.

Юзабилити

Настройка безопасности ― больной вопрос Axis2. На стороне клиента он требует либо встроить параметры времени выполнения в WSDL сервиса, либо настроить их прямо в клиентском коде. В любом случае нужно явно активировать обработку функций безопасности в клиентском коде. На стороне сервера нужно изменить сгенерированный файл services.xml, включив в него параметры времени выполнения, и активировать обработку функций безопасности. Axis2 также имеет тенденцию молча игнорировать все, что ему непонятно в конфигурации политики. Оценка: Axis2 – 5.

Работать с Metro, пожалуй, немного легче, чем Axis2, но он всякий раз требует добавления параметров времени выполнения в WSDL сервиса (или хотя бы ссылки на отдельный документ, определяющий эти параметры, на стороне клиента). Я считаю это неуместным, так как предполагается, что WSDL представляет собой опубликованный договор на обслуживание. Кроме того, Metro предоставляет мало документации по настройке и использованию функций безопасности за пределами комплекса NetBeans/Glassfish. Наконец, по моему опыту, сообщения об ошибках в случае проблем конфигурации, как правило, туманны, что затрудняет выявление их причин. Оценка: Metro – 6.

CXF придерживается наиболее четкого подхода к конфигурации, как правило, с использованием отдельных файлов параметров безопасности времени выполнения на клиенте и сервере. Есть также возможность непосредственной настройки всех параметров с помощью Spring или кода собственной разработки. CXF не только имеет незначительные проблемы конфигурации, но и поддерживает ссылки на внешние политики в WSDL ― важная особенность для организаций, желающих стандартизировать политику безопасности в масштабах предприятия. Наконец, CXF, похоже, лучшее всех обращается с неподдерживаемыми компонентами политики, выдавая предупредительные сообщения, указывающие на то, что эта политика поддерживается не полностью. Оценка: CXF – 8.

Мои оценки суммируются в таблице 1.

Таблица 1. Рейтинг стеков Web-сервисов
Apache Axis2Sun/Oracle MetroApache CXF
Корректность678
Полнота677
Производительность487
Юзабилити568
Итог212830

Эти рейтинги не должны быть определяющими, и в случае их использования при принятии решения о выборе стека обязательно просмотрите мои обоснования и сделайте свои собственные выводы. Кроме того, рейтинги относятся только основным проектам с открытым кодом; коммерческие стеки, основанные на этих версиях, могут иметь свой собственный код безопасности и другие расширения (как в случае с поддержкой сервисов IBM WebSphere, которая основана на среде времени выполнения Axis2, но использует совершенно другой код безопасности). Чтобы понять, какие части рейтинга можно применять, нужно видеть различия между коммерческим кодом и базой с открытым исходным кодом.


Заключение

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

Следующая статья цикла меняет фокус и рассматривает вопросы структуры WSDL-определений сервисов и разработки инструмента для проверки WSDL и их преобразования в рекомендуемую форму.

Ресурсы

  • Оригинал статьи.
  • Axis2: Axis 2 - стек Web-сервисов с открытым исходным кодом от Apache Software Foundation.
  • CXF: CXF ― еще один стек Web-сервисов с открытым исходным кодом от Apache.
  • Metro: Metro ― стек Web-сервисов с открытым исходным кодом, содержащий последние эталонные реализации стандартов Java JAXB 2.x и JAX-WS 2.x.
  • Web Services Interoperability Organization: WS-I предложила практические рекомендации как по основным Web-сервисам, так и по функциям безопасности.
  • Exclusive XML Canonicalization: для цифровых подписей BSP 1.1 требуется алгоритм канонизации, указанный в этой рекомендации W3C.
  • Web Services Interoperability Plug-Fest: мероприятия Plug-Fest организованные Microsoft, способствовали обеспечению взаимодействия между стеками Web-сервисов.
  • Выявление ошибок:
    • Axis2 Jira отслеживает сообщения об ошибках в ядре кода Axis2, а Rampart Jira - в коде управления функциями безопасности;
    • CXF Jira отслеживает все ошибки CXF, причем те из них, которые относятся к безопасности, включены в общую категорию компонентов WS-*;
    • Metro Issue Tracker отслеживает все ошибки Metro, причем те из них, которые относятся к безопасности и другим проблемам WS-*, включены в компонент WSIT.

Комментарии

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=Технология Java, SOA и web-сервисы, Open source
ArticleID=806890
ArticleTitle=Web-сервисы Java: Ситуация в сфере безопасности Web-сервисов
publish-date=03262012