 |
Технология Клиент-Сервер 2010'4
|
|
|
Web-сервисы Java: состояние безопасности в Web-сервисах
Текущее состояние безопасности на основных открытых платформах Web-сервисов
Опубликовано: 29.12.2010
Версия текста: 1.1
Все основные платформы Web-сервисов предоставляют некий уровень поддержки WS-Security и связанных с ним стандартов безопасности Web-сервисов. Три платформы с открытым кодом, рассматриваемые здесь - Apache Axis2, Sun/Oracle Metro и Apache CXF – предоставляют достаточно высокий уровень поддержки этих стандартов. Но эта поддержка во многом существенно различается, включая как обеспечение безопасности, так и настройку конфигурации параметров безопасности.
Одно из существенных различий касается полноты и корректности реализаций безопасности. WS-Security и WS-SecurityPolicy допускают широкое варьирование конфигураций безопасности, включая различные типы ключей и сертификатов, наборы алгоритмов, токены безопасности и спецификации подписей/шифрования. WS-Trust и WS-SecureConversation еще больше расширяют набор возможностей. При таком обилии возможных конфигураций ни на какой платформе Web-сервисов нельзя испытать их все. Даже тестирование отдельных возможностей в изоляции – сложное дело, и большинство платформ даже и не пытается сделать это.
Из этой статьи вы узнаете о проблемах во взаимодействии систем безопасности различных платформ Web-сервисов. Затем вы увидите сравнение Axis2, Metro и CXF по некоторым вопросам корректности и применимости стандартов безопасности.
Функциональная совместимость реализаций безопасности
Стандарты безопасности оговаривают слишком много комбинаций возможностей, чтобы их можно было ответственно протестировать. Многие из стандартов не содержат примеров использования, так что соответствие стандарту – это зачастую вопрос мнения. В результате заявленная поддержка конкретных стандартов платформами редко подвергается широкой проверке.
Вместо попыток проверить соответствие стандарту используется ограниченное число конфигураций безопасности при тестировании самой платформы, и еще более ограниченное – при тестировании взаимодействия с другими платформами. В остальном разработчики всех платформ реагируют на сообщения об ошибках от пользователей, испытывающих проблемы с той или иной конфигурацией или с взаимодействием с другими платформой. Такое ограниченное тестирование сложного набора стандартов означает, что вы часто будете сталкиваться с проблемами, если попробуете отклониться от генеральной линии, заданной создателями платформы. Даже в относительно небольшом наборе конфигураций безопасности, протестированных при обсуждениях безопасности и сравнениях производительности в этой серии статей, я нашел несколько проблем такого рода.
Некоторые усилия по улучшению качества кода безопасности Web-сервисов все же предпринимаются, включая работу отраслевых организаций и выполняемые фирмами-разработчиками тестирование функциональной совместимости.
WS-I Basic Security Profile
С самого начала спецификация Web-сервисов SOAP предлагала широкий выбор для пользователей и разработчиков. Отчасти это "by design". В остальном это недоработки стандарта: ожидаемое поведение описано недостаточно подробно, так что разработчикам остается только гадать, что требуется сделать. Проблема слишком широкого выбора состоит в том, что разработчикам не хватит ресурсов, чтобы полностью протестировать все возможные комбинации, так что платформы Web-сервисов поддерживают некоторые варианты хорошо, некоторые – плохо, а остальные и вовсе не поддерживают. Такая ситуация представляет большую проблему при взаимодействии платформ, поскольку нет никаких гарантий, что разные платформы будут поддерживать одни и те же варианты.
Избыток вариантов был такой проблемой в ранние годы существования SOAP, что была создана рабочая группа производителей специально для уменьшения числа возможных конфигураций путем определения "рекомендуемых" конфигураций. Эта группа, Web Services Interoperability Organization (WS-I), разработала ряд профилей, требующих использовать или избегать использования определенных вариантов (см. Ресурсы). С помощью этих профилей WS-I оказала большое влияние на формирование нынешнего, третьего, поколения платформ Web-сервисов.
Безопасность – это одна из областей, рассматриваемых в профилях WS-I. WS-I Basic Security Profile Version 1.1 (он же BSP 1.1) – это текущий основной документ в области безопасности. Этот документ содержит широкий спектр требований, но, в соответствии с направленностью WS-I, большинство этих требований касается реализаций платформ Web-сервисов, а не пользовательских конфигураций безопасности. BSP 1.1 вообще не касается конфигурации WS-Security в WS-SecurityPolicy, но некоторые из его требований можно толковать в терминах WS-SecurityPolicy.
При использовании цифровых подписей BSP 1.1 требует следовать W3C Exclusive Canonicalization Recommendation, алгоритму канонизации 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 стал движущей силой в этой области, проводя в своем кампусе ряд мероприятий по совместимости, куда приглашаются разработчики различных платформ Web-сервисов (как коммерческих, так и открытых) для участия в тестировании различных сценариев взаимодействия их кода с реализацией Microsoft (см. Ресурсы). Безопасность является главной темой этих мероприятий.
Такое тестирование взаимодействия помогло создать базовый уровень совместимости между платформами, но выигрыш от этого невелик из-за малого числа проверенных конфигураций. Фокус на взаимодействии с реализацией Microsoft (вместо набора тестов, основанного на существующих стандартах) также является ограничением, хотя на практике такое реализуется куда проще, чем полное тестирование совместимости множества платформ.
Проблемы и ограничения безопасности
В этой серии статей я тестировал разнообразные конфигурации безопасности трех платформ Web-сервисов, обнаружив по несколько проблем в каждой платформе. Ограниченное тестирование возможностей совместной работы (с использованием одной платформы в качестве клиента, и другой – в качестве сервера, применялось только для тестов WS-SecureConversation) выявило еще больше проблем. Одна из платформ, Apache Axis2, показала также существенные проблемы с производительностью. Обо всех этих проблемах было доложено разработчикам каждой из платформ, и некоторые из них были устранены в последних версиях. В этом разделе я опишу текущее состояние трех платформ в аспекте проведенных тестов.
Проблемы Axis2
Проблемы, обнаруженные в Axis2, включают работу с политикой WS-SecureConversation, где определение политики начальной загрузки, кажется, полностью проигнорировано. Это означает, что Axis2 использует для поддержки WS-SecureConversation заранее заготовленную конфигурацию, и, стало быть, совместим только с платформами, использующими такую же конфигурацию.
Если говорить о рантайме безопасности, у Axis2 есть большая проблема с обработкой симметричных связываний на клиентской стороне (как говорилось в статье "WS-Security without client certificates", http://www.ibm.com/developerworks/java/library/j-jws17/index.html). Исполнение клиентской части прогрессивно замедляется по мере роста числа запросов. Я считаю это крупным багом, а не проблемой с производительностью, из-за прогрессирующего характера проблемы.
Работа с безопасностью в Axis2 также страшно тормозит. Эта проблема производительности скорее всего связана с несовместимостями между объектной моделью 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 and WS-SecureConversation". Проблема в данном случае состоит в том, что политика использует разные наборы алгоритмов при обмене начальными сообщениями с Security Token Service (STS) и при дальнейшем обмене сообщениями с сервисом. Metro игнорирует это и использует один и тот же алгоритм в обоих случаях. Это не такая существенная проблема, как предыдущая, поскольку на практике мало причин использовать разные наборы алгоритмов, но это все-таки ошибка.
Наконец, у Metro есть также проблемы с однонаправленным шифрованием и подписями, описанные в статье "Understanding WS-Policy". Ни одна из этих проблем в последней версии Metro не устранена.
Проблемы CXF
Как и в случае других платформ, в CXF я тоже нашел проблемы при тестировании. Почти все они были исправлены в новых версиях раньше, чем была опубликована статья. Исключение составили проблемы с однонаправленным шифрованием и подписями, описанные в статье "Understanding WS-Policy" – но и они исправлены в версии CXF 2.3.1.
Сравниваем платформы
...
Заключение
Все три open source-платформы Web-сервисов, рассмотренные здесь, предоставляют хорошую поддержку безопасности. У каждой из платформ есть слабые и сильные стороны в аспекте безопасности, и в этой статье я сравнил их на основании собственного опыта работы.
Системы отслеживания ошибок:
........................
С полным содержанием данной статьи можно ознакомиться в печатной версии журнала
Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы
то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских
прав.
Ваши предложения и комментарии мы ожидаем по адресу: mag@rsdn.ru
Copyright ©
1994-2002 Оптим.ру
Home
Поиск
Software
Издания
Работа
