Web-сервисы Java: Высокая цена (WS-)Security

Насколько накладные расходы при использовании WS-Security выше по сравнению с SSL, и когда игра стоит свеч

WS-Security предлагает мощные средства для обеспечения безопасности приложений на основе Web-сервисов, и для многих таких приложений эти функции имеют первостепенное значение. Но они дорого обходятся с точки зрения производительности и накладных расходов, связанных с передачей сообщений. Денис Сосновский продолжает свой цикл статей о Web-сервисах Java, исследуя, как использование WS-Security или WS-SecureConversation влияет на производительность Axis2 и когда когда лучшим выбором становится более простой (и быстродействующий) альтернативный вариант соединений с защитой HTTPS.

Денис Сосноски, консультант, 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.



19.12.2011

WS-Security обеспечивает полный набор средств безопасности для приложений Web-сервисов, опираясь на устоявшиеся стандарты криптографии, XML-шифрования и электронной подписи. Пользуясь WS-Policy и WS-SecurityPolicy, можно задать параметры для конкретного приложения, так что клиенты будут автоматически настраиваться на доступ к сервису. Широкая поддержка этих стандартов на множестве платформ и технологий Web-сервисов гарантирует хорошее взаимодействие (которое становится все лучше).

Но наряду с этими преимуществами WS-Security имеет свои недостатки. В двух последних статьях этого цикла мы показали, что WS-Security может быть сложным в настройке, и передаваемые им сообщения порой становится слишком громоздки. Так когда же преимущества, предоставляемые WS-Security, оправдывают эти затраты? В настоящей статье мы подробнее рассмотрим издержки, создаваемые WS-Security и его продолжением WS-SecureConversation во время выполнения (с точки зрения накладных расходов на обработку и дополнительной нагрузки), и поговорим о том, как применять WS-Security, чтобы это имело смысл для конкретного приложения.

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

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

Анализ производительности

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

Выполнение теста производительности

Для тестирования используется сервис извлечения сейсмических данных. Он основан на реальной базе данных более чем по 93 000 землетрясений, которые происходили в мире в течение ряда лет. В запросах к сервису указываются требуемые диапазоны значений широты, долготы, даты или силы землетрясения, и он возвращает все подходящие случаи землетрясений, сгруппированные по регионам, в хронологическом порядке. Вся база данных хранится в памяти и индексирована для ускорения обработки запросов, так что почти все время обработки каждого запроса тратится на фактическую обработку кода Web-сервиса (включая код привязки данных, который преобразует их в XML и обратно).

В Листинге 1 приведен пример запроса к сервису и ответа (отформатированный по ширине страницы):

Листинг 1. Пример запроса и ответа
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns1:matchQuakes xmlns:ns1="http://ws.sosnoski.com/seismic/types">
      <ns1:min-date>2001-08-08T16:31:05.752+00:00</ns1:min-date>
      <ns1:max-date>2001-08-14T23:51:31.499+00:00</ns1:max-date>
      <ns1:min-long>160.4685</ns1:min-long>
      <ns1:max-long>178.19693</ns1:max-long>
      <ns1:min-lat>-42.423557</ns1:min-lat>
      <ns1:max-lat>-30.44976</ns1:max-lat>
    </ns1:matchQuakes>
  </soapenv:Body>
</soapenv:Envelope>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns1:results xmlns:ns1="http://ws.sosnoski.com/seismic/types" count="9">
      <ns1:result-set>
        <ns1:area-name>New Zealand Region</ns1:area-name>
        <ns1:regions count="0">
          <ns1:region ident="rgn159" index="159">NORTH ISLAND,
              NEW ZEALAND</ns1:region>
          <ns1:region ident="rgn160" index="160">OFF E. COAST OF N. ISLAND,
              N.Z.</ns1:region>
        </ns1:regions>
        <ns1:quakes count="9">
          <ns1:quake time="2001-08-11T09:52:54.000+00:00" millis="1000"
              latitude="-37.6499" longitude="177.74" depth="83.0" magnitude="4.4"
              method="ML" region="rgn160"/>
          <ns1:quake time="2001-08-11T09:52:55.000+00:00" millis="0"
              latitude="-37.71" longitude="177.77" depth="70.0" magnitude="4.5"
              method="ML" region="rgn160"/>
          <ns1:quake time="2001-08-11T15:02:47.000+00:00" millis="5600"
              latitude="-38.0429" longitude="175.632" depth="299.8" magnitude="4.6"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-12T07:42:41.000+00:00" millis="7000"
              latitude="-37.97" longitude="175.97" depth="289.0" magnitude="4.3"
              method="MB" region="rgn159"/>
          <ns1:quake time="2001-08-12T22:37:58.000+00:00" millis="5600"
              latitude="-38.3839" longitude="176.121" depth="163.2" magnitude="4.0"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-12T23:25:09.000+00:00" millis="6700"
              latitude="-39.9559" longitude="176.115" depth="76.0" magnitude="4.0"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-13T05:10:07.000+00:00" millis="4300"
              latitude="-37.5859" longitude="176.651" depth="189.0" magnitude="4.3"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-14T02:43:18.000+00:00" millis="2900"
              latitude="-38.3699" longitude="175.902" depth="193.4" magnitude="4.5"
              method="ML" region="rgn159"/>
          <ns1:quake time="2001-08-14T18:02:35.000+00:00" millis="5400"
              latitude="-37.8159" longitude="176.375" depth="193.3" magnitude="4.5"
              method="ML" region="rgn159"/>
        </ns1:quakes>
      </ns1:result-set>
    </ns1:results>
  </soapenv:Body>
</soapenv:Envelope>

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

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

Результаты, приведенные в этой статье, основаны на двух последовательностях запросов. Первая использует 1000 запросов с параметрами, отрегулированными так, что каждый запрос соответствует лишь небольшой части всей базы данных землетрясений (на 1000 запросов возвращается всего 816 подходящих землетрясений). Вторая последовательность использует 100 запросов, которым соответствует большая часть базы данных (в ответ на 100 запросов возвращаются 176 745 подходящих землетрясений). Каждая последовательность запросов выполняется много раз в различных конфигурациях, и для каждой конфигурации сохраняются только результаты с наилучшим временем.

Тесты проводились на 64-разрядной системе Linux® Mandriva 2009.1 с процессором Athlon X2 5400+ и 4 ГБ оперативной памяти с применением 32-разрядной JVM Sun Java 1.6.0_13. Код сервера работал на Tomcat 6.0.20, настроенным на использование хипа размером 1024 МБ, а код клиента ― на использование хипа размером 512 МБ. Применялся Axis2 версии 1.5 с текущей сборкой кода Rampart. (На момент проведения испытаний еще не было версии Rampart, соответствующей коду Axis2 1.5.) Как ни странно, для выполнения полного набора тестов потребовался хип Tomcat размером 1024 МБ (для каждой конфигурации безопасности использовалось отдельное приложение Web-сервиса); при первоначальном тестировании с хипом размером 256 МБ тесты WS-Security иногда заканчивались странными, бессмысленными сообщениями об ошибке (типа "Сообщение SOAP НЕ ДОЛЖНО содержать Document Type Declaration (DTD)" при отсутствии DTD) или java.lang.OutOfMemoryError.

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

  • plain : без защиты;
  • ssl : соединение с сервером через HTTPS;
  • username : неформатированный UsernameToken WS-Security в запросах;
  • sign : подписание тела и заголовков с меткой времени посредством WS-Security;
  • encr : шифрование тела сообщения посредством WS-Security;
  • signencr : подписание тела и заголовков с меткой времени и шифрование текста сообщения посредством WS-Security.

Фактическое время тестирования составляло от 4 с для конфигурации plain до 55 секунд для конфигурации signencr. На рисунке 1 показано относительное время выполнения тестов, для удобства сравнения нормализованное по усредненному значению времени выполнения в конфигурации plain.

Рисунок 1. Сравнение времени выполнения тестов
Сравнение времени выполнения тестов

Как видно из рисунка 1, шифрование Secure Sockets Layer (SSL) – сейчас это технически Transport Layer Security (TLS), но для узнаваемости мы будем использовать старую аббревиатуру - обеспечивает производительность, близкую к незащищенному случаю (хотя она лучше работает для длинных сообщений, чем для коротких, требуя почти на 80% больше времени в случае коротких сообщений против 20% в случае длинных). Однако использование WS-Security приводит к огромному снижению производительности. Простое добавление заголовков UsernameToken к запросам сообщений вызывает снижение производительности примерно до того же уровня, что и SSL для коротких сообщений, и в несколько раз большее, чем SSL в применении к длинным сообщениям. В случае же сочетания подписи с шифрованием время испытаний увеличивается более чем на 2100% по сравнению с незащищенными сообщениями.

Отчасти этот удар по производительности со стороны WS-Security связан с изъяном в реализации обработчика Rampart, который всякий раз, когда задействован Rampart, преобразовывает каждое сообщение запроса и ответа в форму Document Object Model (DOM) (даже если никакой обработки сообщения, связанной с безопасностью, не требуется). Эта проблема должна быть исправлена в выпуске Rampart 1.5, прилагаемом к Axis2 1.5. В зависимости от способа исправления время выполнения теста UsernameToken может существенно улучшиться. Но на другие составляющие времени выполнения WS-Security это исправление, вероятно, не повлияет.

Другой причиной снижения производительности WS-Security служат сочетание способа работы XML Signature/XML Encryption и библиотек, используемых для реализации WS-Security и этих стандартов XML. Как вы помните из статьи Подпись и шифрование WS-Security Axis2, для подписания XML-сообщений требуется шаг, называемый канонизацией, на котором XML перед вычислением значения подписи преобразуется в конкретную каноническую форму. Стандарт требует этого шага, потому что было принято решение сохранять подписи даже после разложения парсером и регенерации XML. Хотя это, безусловно, полезное свойство XML Signature, оно добавляет значительные накладные расходы на обработку. Отчасти потому, что канонизацию проще всего выполнять с помощью модели DOM, все библиотеки безопасности XML написаны для работы с DOM-представлениями XML. (Вот почему обработчики Rampart создают DOM, даже когда работают с сервисом или клиентом, ― исходя из того, что DOM в любом случае понадобится). Как видно из значений времени выполнения UsernameToken, шаг преобразования данных в представление DOM вызывает заметные накладные расходы при работе WS-Security. В случае длинных ответных сообщений эти издержки почти равны времени фактической обработки подписи или шифрования (это видно на рисунке 1, если сравнить красную полосу для случая username – когда создание DOM служит единственным источником накладных расходов – со случаями sign и encr, когда после создания DOM выполняется фактическая криптографическая обработка).

Помимо проблемы DOM, значительная часть накладных расходов WS-Security связана с интенсивными вычислениями по созданию дайджестов и шифрованию данных. Эта часть работы требуется независимо от способа реализации, так что существует предел возможного улучшения времени обработки WS-Security. В будущих статьях этого цикла мы сравним производительность некоторых других реализаций WS-Security с реализацией Axis2/Rampart – но в большинстве из них применяются те же базовые библиотеки, так что не ждите каких-то существенных различий.

WS-SecureConversation

WS-SecureConversation – это стандарт безопасного обмена с участием нескольких сообщений, основанный на стандартах WS-Security и WS-Trust. Он использует контекст текущего обмена сообщениями, поэтому WS-SecureConversation потенциально более эффективен, чем WS-Security. Дистрибутив Rampart включает в себя отдельный модуль rahas, который позволяет выдавать маркеры доступа, требуемые WS-SecureConversation. Он содержит также пример конфигурации политики (samples/policy/sample04) с использованием WS-SecureConversation, который положен в основу политики, используемой в тестах производительности.

Политика WS-SecureConversation (здесь не показана, но присутствует в загрузке как secureconversation-policy-client.xml) включает в себя элемент <sp:SecureConversationToken>, в котором указано, какой тип маркера доступа будет использоваться для обмена сообщениями, и приведены параметры доступа, которые должны применяться к сообщениям обмена маркерами. Последние передаются вместе с обычными сообщениями между клиентом и сервисом с использованием операций, реализованных в модуле rahas – так что при использовании WS-SecureConversation между клиентом и сервером проскакивают пары сообщений запрос-ответ, как показано в листинге 2. Эти добавленные сообщения обмена маркерами можно отличить от сообщений приложения по разным используемым ими параметрам безопасности, настроенным в политике, а также по специальному запросу http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT и кодам ответных действий http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT, которые определены в WS-SecureConversation.

Листинг 2. Пример запроса и ответа
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
  <soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
    <wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
        soapenv:mustUnderstand="1">
      ...
    </wsse:Security>
    <wsa:To
    >http://localhost:8800/axis2/services/seismic-secureconversation</wsa:To>
    <wsa:ReplyTo>
      <wsa:Address
      >http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
    </wsa:ReplyTo>
    <wsa:MessageID>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:MessageID>
    <wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</wsa:Action>
  </soapenv:Header>
  <soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-30222347">
    <xenc:EncryptedData ...>
      ...
    </xenc:EncryptedData>
  </soapenv:Body>
</soapenv:Envelope>

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
    <wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
        soapenv:mustUnderstand="1">
      ...
    </wsse:Security>
    <wsa:To
    >http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
    <wsa:MessageID>urn:uuid:1BCDE6BE423F5FDE791246409571325</wsa:MessageID>
    <wsa:Action
    >http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</wsa:Action>
    <wsa:RelatesTo>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:RelatesTo>
  </soapenv:Header>
  <soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-5148380">
    <xenc:EncryptedData ...>
      ...
    </xenc:EncryptedData>
  </soapenv:Body>
</soapenv:Envelope>

Для сравнения производительности с обычным WS-Security, использующим сертификаты, конфигурация WS-SecureConversation настроена на использование маркера сеанса только для шифрования тела сообщений. На рисунке 2 показано, как соотносится результирующее время выполнения теста в конфигурациях plain и encr, опять же для удобства сравнения нормализованных по среднему значению времени в конфигурации plain.

Рисунок 2. Сравнение времени выполнения WS-SecureConversation
Сравнение времени выполнения WS-SecureConversation

Как видно из рисунка 2, шифрование WS-SecureConversation обеспечивает значительное улучшение производительности по сравнению с WS-Security. Это особенно справедливо для коротких сообщений, с которыми конфигурация WS-SecureConversation справляется почти вдвое быстрее, чем шифрование WS-Security с применением сертификатов. Для длинных сообщений выигрыш в производительности значительно менее существенен, но и в этом случае WS-SecureConversation работает на 18% быстрее.

Сравнение размера сообщений

Как мы уже видели в предыдущих статьях этого цикла, WS-Security может добавлять много текста в заголовки сообщений SOAP. Это может оказывать значительное влияние на производительность, когда данные передаются между клиентом и сервером по сети (в отличие от тестов производительности, выполняемых в этой статье, в которых клиент и сервер работают в одной и той же системе). То, какое влияние этот дополнительный размер оказывает на производительность, определяется качеством сетевого соединения между клиентом и сервером, но ясно, что чем длиннее сообщение, тем медленнее происходит обмен.

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

Рисунок 3. Сравнение размера сообщений
Сравнение размера сообщений

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


Когда применять WS-Security

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

Хранение тайны

Сохранение конфиденциальности ― один из важнейших аспектов безопасности. WS-Security использует XML-шифрование для сохранения содержания сообщения в тайне от всех, кроме предполагаемого получателя, как правило, опираясь на открытые ключи, завернутые в цифровые сертификаты. Шифрование может применяться ко всему сообщению или к отдельным его частям, и даже можно использовать несколько уровней шифрования для управления тем, какая информация будет доступна каждому участнику системы многостороннего обмена сообщениями.

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

Но и WS-Security, и XML-шифрование, когда речь идет о сохранении конфиденциальности, для многих приложений – это перебор. Если сервис непосредственно контактирует с клиентами (а не опосредованно, через другие серверы) и выполняет всю необходимую обработку напрямую, достаточно использовать для доступа SSL-соединение (HTTPS), чтобы обеспечить надежную гарантию конфиденциальности со значительно более низкими потерями производительности, чем с WS-Security. Однако этот подход работает только при прямом подключении клиентов. В противном случае, если сервис должен передавать информацию другим сервисам, мы возвращаемся к той же ситуации, что и с уязвимыми Web-сайтами онлайн-магазинов, где для передачи данных кредитной карты в торговую систему используется безопасное соединение, но нет никаких гарантий, что эта информация будет безопасно храниться на сервере сайта.

Поддержание целостности данных

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

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

Опять же, WS-Security и XML-подпись может быть перебором, если сервис работает непосредственно с клиентом и выполняет всю необходимую обработку внутренне. SSL-соединение не только сохранит конфиденциальность данных, но и предотвратит возможность их изменения в пути – однако только между одним клиентом и сервером. Если сервер передает данные в другие системы, эти системы не дают никаких гарантий, что данные не были изменены на сервере.

Гарантия подлинности

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

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

Вновь возвращаясь к примеру системы онлайн-торговли: подпись клиента на платежном поручении позволит сохранить его в банковской системе и позднее предъявить, если возникнет какой-нибудь спор. Это позволит банковской системе доказать , что платеж был уполномочен клиентом, и тем самым избавить себя от любой ответственности.

Дополнительные возможности

Кроме основных функций по обеспечению конфиденциальности, целостности и подлинности, WS-Security предоставляет многие другие возможности для выполнения особых требований по безопасности. Например, простая функция UsernameToken обеспечивает стандартизированный способ передачи сервису результатов базовой проверки подлинности пользователя. Другие функции WS-Security позволяют вводить в процесс обмена сообщениями SOAP маркеры Security Assertion Markup Language (SAML) и другие виды информации, связанной с безопасностью. Если в Web-сервисах нужно применять информацию по безопасности подобного типа, то для ее передачи лучше воспользоваться поддержкой WS-Security, поскольку там определены стандартные форматы и процедуры, которые, скорее всего, надежнее тех, которые можно создать самостоятельно.

Сокращение накладных расходов WS-Security

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

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

Для продолжительного обмена сообщениями между клиентами и сервером можно использовать также WS-SecureConversation (даже через посредников), что дает относительно скромный, но все же заметный выигрыш в производительности по сравнению с сертификатами WS-Security. WS-SecureConversation особенно хорошо работает при обмене относительно небольшими сообщениями, когда дополнительные накладные расходы сертификатов и асимметричного шифрования могут быть большими по сравнению с прямым (симметричным) шифрованием тела сообщения.

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


Заключение

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

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


Загрузка

ОписаниеИмяРазмер
Исходный код для этой статьиj-jws6.zip1,6 МБ

Ресурсы

Научиться

Получить продукты и технологии

  • Apache Axis2: загрузите последнюю версию Axis2.
  • Rampart: загрузите модуль Rampart для Axis2.

Комментарии

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=781638
ArticleTitle=Web-сервисы Java: Высокая цена (WS-)Security
publish-date=12192011