Войти
Безопасность веб-служб (WS-Security, WSS ) расширение SOAP для применения безопасности к веб-службам. Он входит в состав спецификаций веб-служб и был опубликован OASIS.
. Протокол определяет, как можно обеспечить целостность и конфиденциальность сообщений, и позволяет передавать различные форматы токенов безопасности, например Язык разметки утверждений безопасности (SAML), Kerberos и X.509. Его основное внимание уделяется использованию подписи XML и шифрования XML для обеспечения сквозной безопасности.
WS-Security описывает три основных механизма:
Спецификация допускает различные форматы подписи, алгоритмы шифрования и несколько доверенных доменов, и открыт для различных моделей токенов безопасности, таких как:
Форматы и семантика токенов определены в связанных документах профиля.
WS-Security включает в себя функции безопасности в заголовке сообщения SOAP, работая на прикладном уровне.
Эти механизмы сами по себе не обеспечивают полного решения безопасности для веб-служб. Напротив, эта спецификация является строительным блоком, который можно использовать вместе с другими расширениями веб-служб и высокоуровневыми протоколами для конкретных приложений, чтобы приспособиться к широкому спектру моделей безопасности и технологий безопасности. В общем, WSS сам по себе не дает никаких гарантий безопасности. При реализации и использовании структуры и синтаксиса разработчик должен убедиться, что результат не уязвим.
Управление ключами, доверительная начальная загрузка, объединение и согласование технических деталей (шифры, форматы, алгоритмы) выходят за рамки WS-Security.
Если требуется посредник SOAP, а этот посредник не является более или менее надежным, сообщения должны быть подписаны и, возможно, зашифрованный. Это может быть случай прокси-сервера уровня приложения на периметре сети, который завершает соединения TCP (протокол управления передачей).
Один из методов неотказуемости - это запись транзакций в журнал аудита, который подлежит определенным мерам безопасности. Цифровые подписи, которые поддерживает WS-Security, обеспечивают более прямое и поддающееся проверке доказательство отказа от авторства.
Хотя почти все службы SOAP реализуют привязки HTTP, теоретически можно использовать другие привязки, такие как JMS или SMTP; в этом случае потребуется сквозная безопасность.
Даже если веб-служба полагается на безопасность транспортного уровня, службе может потребоваться знать о конечном пользователе, если служба ретранслируется через (HTTP-) обратный прокси. Заголовок WSS может использоваться для передачи токена конечного пользователя, за который отвечает обратный прокси.
WS-Security добавляет значительные накладные расходы на обработку SOAP из-за увеличенного размера сообщения по проводам, XML и криптографическая обработка, требующие более быстрых процессоров и большего объема памяти и пропускной способности.
В ходе оценки в 2005 году было измерено 25 типов SOAP-сообщений разного размера и сложности, обработанных WSS4J как с WS-Security, так и с WS-SecureConversation на процессоре Pentium 4 / 2,8 ГГц. Были получены следующие результаты:
Другой тест в 2006 году привел к этому сравнению:
| Механизм безопасности | Сообщений в секунду |
|---|---|
| WS-Security (X.509) XML-подпись и шифрование | 352 |
| XML-подпись и шифрование WS-SecureConversation | 798 |
| Безопасность транспортного уровня | 2918 |
Первоначально полагались веб-службы о базовой транспортной безопасности. Фактически, большинство реализаций все еще работают. Поскольку SOAP допускает несколько транспортных привязок, таких как HTTP и SMTP, необходим механизм безопасности на уровне SOAP. Другим фактором было отсутствие сквозной безопасности из-за зависимости от транспортной безопасности.
Протокол был первоначально разработан IBM, Microsoft и VeriSign. Их первоначальная спецификация была опубликована 5 апреля 2002 года, а 18 августа 2002 года было выпущено дополнение.
В 2002 году в Технический комитет OASIS WSS были представлены два предложения: безопасность веб-сервисов (WS-Security) и Дополнение по безопасности веб-служб. В результате был опубликован WS-Security:
Стандарт версии 1.0, опубликованный OASIS, содержал ряд существенных отличий от стандарта, предложенного консорциумом IBM, Microsoft и VeriSign. Многие системы были разработаны с использованием предложенного стандарта, и различия сделали их несовместимыми с системами, разработанными в соответствии со стандартом OASIS.
Некоторые называют спецификацию до OASIS «Проектом 13 WS-Security» или Базовую спецификацию безопасности веб-служб. Однако эти имена малоизвестны, и действительно сегодня трудно четко определить, использует ли приложение или сервер спецификацию до или после OASIS. В большинстве сообщений на форуме для ссылки на версию до OASIS используется ключевое слово «WSSE», поскольку оно требовало использования префикса «wsse» XML namespace для URL-адреса (и аналогичных URL-адресов разных версий).
Протокол официально называется WSS и разработан комитетом Oasis-Open.
Следующие предварительные спецификации связаны с WS-Security: WS-Federation,.
Следующие утвержденные спецификации связаны с WS-Security: WS-Policy, WS-SecureConversation, WS-Trust, ID-WSF.
Следующие архитектуры используют WS-Security:.
В ситуациях «точка-точка» конфиденциальность и целостность данных также могут быть обеспечены в веб-службах с помощью Безопасность транспортного уровня (TLS), например, путем отправки сообщений по HTTPS. WS-Security, однако, решает более широкую проблему поддержания целостности и конфиденциальности сообщений до тех пор, пока сообщение не будет отправлено с исходного узла, обеспечивая так называемую сквозную безопасность.
Применение TLS может значительно снизить накладные расходы. устраняя необходимость кодировать ключи и подписи сообщений в XML перед отправкой. Проблемой при использовании TLS может стать то, что сообщения должны проходить через прокси-сервер уровня приложения, поскольку он должен иметь возможность видеть запрос на маршрутизацию. В таком примере сервер будет видеть запрос, исходящий от прокси, а не от клиента; это можно обойти, если прокси-сервер будет иметь копию ключа и сертификата клиента или иметь сертификат подписи, которому доверяет сервер, с помощью которого он мог бы сгенерировать пару ключ / сертификат, совпадающую с таковыми у клиента. Однако, поскольку прокси-сервер не работает с сообщением, он не обеспечивает сквозную безопасность, а только обеспечивает безопасность точка-точка.
