Ws security что это за программа

Содержание

Защищенные веб-службы: REST через HTTPS и SOAP + WS-Security. Что лучше?

Я не эксперт по безопасности, но я предпочитаю создание веб-сервисов в стиле REST.
При создании новой службы, которая должна иметь защищенные данные. Мы вступили в дискуссию о том, какой подход более безопасен — REST с HTTPS или SOAP WS с WS-Security.
У меня создается впечатление, что мы могли бы использовать HTTPS для всех вызовов веб-сервисов, и этот подход был бы безопасным. Как я смотрю на это, «если HTTPS достаточно хорош для банковских и финансовых веб-сайтов, это достаточно хорошо для меня». Опять же, я не эксперт в этом пространстве, но я думаю, что эти люди серьезно подумали об этой проблеме и устраивают HTTPS.
Сотрудник не согласен и говорит, что SOAP и WS-Security — единственный способ пойти.
На этом веб-сайт выглядит повсюду.
Может быть, сообщество здесь может взвесить плюсы и минусы каждого? Спасибо!

спросил(а) 2009-05-12T19:14:00+04:00 13 лет, 7 месяцев назад
добавить комментарий
пожаловаться

WS-Security

HTTPS обеспечивает передачу сообщения по сети и обеспечивает некоторую уверенность клиента в идентификации сервера. Это то, что важно для вашего банка или онлайн-брокера. Их заинтересованность в аутентификации клиента не в том, что касается компьютера, а в вашей личности. Поэтому для аутентификации вас используются номера карт, имена пользователей, пароли и т.д. Затем обычно принимаются некоторые меры предосторожности, чтобы гарантировать, что представления не были подделаны, но в целом все, что происходит на сессии, считается инициированным вами.
WS-Security обеспечивает конфиденциальность и защиту целостности от создания сообщения к нему. Поэтому вместо того, чтобы гарантировать, что содержимое сообщений может быть прочитано только правильным сервером, он гарантирует, что его можно будет читать только правильным процессом на сервере. Вместо того, чтобы предполагать, что все сообщения в безопасно инициированном сеансе принадлежат аутентифицированному пользователю, каждый из них должен быть подписан.
Здесь есть забавное объяснение с участием голых мотоциклистов: http://blogs.msdn.com/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked.aspx
Итак, WS-Security предлагает больше защиты, чем HTTPS, и SOAP предлагает более богатый API, чем REST. Мое мнение таково, что, если вам действительно не нужны дополнительные функции или защита, вы должны пропустить накладные расходы SOAP и WS-Security. Я знаю, что это небольшая копия, но решения о том, насколько защита фактически оправдана (а не только то, что было бы здорово для создания), должны быть сделаны теми, кто знает проблему глубоко.

ответил(а) 2009-05-12T19:44:00+04:00 13 лет, 7 месяцев назад
добавить комментарий
пожаловаться

Безопасность REST зависит от транспорта, в то время как безопасность SOAP отсутствует.
REST наследует меры безопасности от основного транспорта, тогда как SOAP определяет свой собственный через WS-Security.

JAX-WS Security Basic Authentication-1( WebService and Client)

Когда мы говорим о REST, через HTTP — все применяемые меры безопасности HTTP наследуются, и это называется безопасностью транспортного уровня.
Безопасность на уровне транспорта защищает ваше сообщение только при его проводе — как только он покидает провод, сообщение больше не защищается. Но, с WS-Security, его безопасность на уровне сообщений — даже несмотря на то, что сообщение выходит из транспортного канала, оно будет по-прежнему защищено. Кроме того, с защитой уровня сообщений вы можете частично зашифровать сообщение [не все сообщение, а только те части, которые вы хотите], но с безопасностью транспортного уровня вы не можете этого сделать.
WS-Security имеет меры для аутентификации, целостности, конфиденциальности и неотказуемости, в то время как SSL не поддерживает отказ от него [с помощью двухстороннего OAuth, который он делает].
По производительности SSL значительно быстрее WS-Security.
Спасибо.

ответил(а) 2011-08-28T04:55:00+04:00 11 лет, 3 месяца назад
добавить комментарий
пожаловаться

Технически, способ, которым вы его сформулировали, не является правильным, поскольку связь метода SOAP небезопасна, и метод REST ничего не сказал об аутентификации законных пользователей.
HTTPS предупреждает злоумышленников из eavesdropping об обмене данными между двумя системами. Он также проверяет, что хост-система (сервер) — это фактически хост-система, к которой пользователь хочет получить доступ.
WS-Security предотвращает доступ неавторизованных приложений (пользователей) к системе.
Если система RESTful имеет способ аутентификации пользователей, а SOAP-приложение с WS-Security использует HTTPS, то действительно обе оба являются безопасными. Это просто другой способ представления и доступа к данным.

ответил(а) 2009-05-12T19:29:00+04:00 13 лет, 7 месяцев назад
добавить комментарий
пожаловаться

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

ответил(а) 2009-05-12T19:25:00+04:00 13 лет, 7 месяцев назад
добавить комментарий
пожаловаться

Как вы говорите, REST достаточно хорош для банков, поэтому должно быть достаточно для вас.
Существует два основных аспекта безопасности: 1) шифрование и 2) идентификация.
Передача в SSL/HTTPS обеспечивает шифрование по кабелю. Но вам также необходимо убедиться, что оба сервера могут подтвердить, что они знают, с кем они разговаривают. Это может быть через SSL-клиентские сертификаты, разделять секреты и т.д.
Я уверен, что можно сделать так, что SOAP «более безопасен», но, вероятно, не имеет никакого отношения. Аналогия аналогов в голом миксере хороша, но если точность будет означать, что весь интернет небезопасен.

ответил(а) 2009-07-04T10:39:00+04:00 13 лет, 5 месяцев назад
добавить комментарий
пожаловаться

У меня еще нет ответа, чтобы добавить комментарий, или я бы просто добавил это к ответу Белла. Я думаю, что Белл очень хорошо подвел итог плюсам и минусам этих двух подходов. Еще несколько факторов, которые вы можете рассмотреть:
1) Должны ли запросы между вашими клиентами и вашим сервисом проходить через посредников, которым нужен доступ к полезной нагрузке? Если это так, то WS-Security может быть лучше.
2) Фактически можно использовать SSL, чтобы обеспечить серверу уверенность в идентификации клиентов с помощью функции, называемой взаимной аутентификацией. Тем не менее, это не очень удобно использовать за пределами некоторых очень специализированных сценариев из-за сложности его настройки. Итак, Белл прав, что WS-Sec намного лучше подходит.
3) SSL вообще может быть немного медведем для настройки и поддержки (даже в более простой конфигурации), в основном из-за проблем с управлением сертификатами. Наличие того, кто знает, как это сделать для вашей платформы, будет большим плюсом.
4) Если вам может понадобиться сделать некоторую форму сопоставления учетных данных или федерации удостоверений, то WS-Sec может стоить накладных расходов. Не то чтобы вы не могли сделать это с помощью REST, у вас просто меньше структуры, чтобы помочь вам.
5) Получение всех решений WS-Security в правильные места на стороне клиента может быть больнее, чем вы думаете.
В конце концов, хотя это действительно зависит от многих вещей, которые мы вряд ли узнаем. В большинстве ситуаций я бы сказал, что любой из этих подходов будет «достаточно безопасным» и поэтому не должен быть основным решающим фактором.

ответил(а) 2009-05-13T06:25:00+04:00 13 лет, 7 месяцев назад
добавить комментарий
пожаловаться

Brace yourself, here there another coming 🙂

Сегодня мне пришлось объяснить моей девушке разницу между выразительной силой WS-Security, а не HTTPS. Она компьютерный ученый, поэтому, даже если она не знает все XML mumbo jumbo, она понимает (может быть, лучше меня), что такое шифрование или подпись. Однако я хотел получить сильное изображение, которое могло бы заставить ее понять, для чего полезны, а не как они реализованы (это произошло немного позже, она не избежала этого:)).
Так оно и происходит. Предположим, что вы голые, и вам нужно управлять своим мотоциклом в определенном месте.
В случае (A) вы проходите через прозрачный туннель: ваша единственная надежда не быть арестованным за непристойное поведение — это то, что никто не смотрит. Это не самая безопасная стратегия, с которой вы можете выйти. (обратите внимание на пот-каплю с парня на лоб:-)). Это эквивалентно POST в ясном виде, и когда я говорю «эквивалент», я имею в виду.
В случае (B) вы находитесь в лучшей ситуации. Туннель непрозрачен, поэтому пока вы путешествуете в него, ваш общедоступный отчет безопасен. Однако это все еще не лучшая ситуация. Вам все равно придется уйти из дома и добраться до входа в туннель, а когда-то за туннелем, вероятно, вам придется выйти и погулять где-нибудь. и это идет на HTTPS.

Еще в рубрике

Простой php-код в методе post, который запрашивает у веб-службы
Публикация AzureML Webservice из R требует внешней утилиты zip
Wordpress vs php или asp.net
Извлечение обложек альбомов/изображений из веб-службы

Другие вопросы

Запуск Spring Boot CLI с помощью команды «Spring run app.groovy» дает ошибку «bash: spring: command not found»

Источник: progi.pro

Ws-security в SoapUI Pro

openssl req -new -key privkey1.key -out request1.csr

(второй раз privkey2.key и request2.csr соответственно). У вас в результате получились две пары «запрос-ключ» (privkey1.key request2.csr). Два запроса на сертификат нужно отправить аналитикам системы, они, в свою очередь, подписав эти запросы и добавив в свои хранилища, отправят вам обратно сертификаты в формате *.crt для доступа к их системе. Пусть первой паре «запрос-закрытый ключ» будет соответствовать сертификат ssl.crt, который будет использоваться для обеспечения двустороннего ssl, второй паре – trust.crt, этот сертификат будет использоваться для подписывания сообщений.
Когда мы получили эти сертификаты, мы можем проверить, доступен ли нам веб-сервис и все ли правильно с сертификатами даже из браузера. Для этого нам нужно добавить пару «закрытый ключ-сертификат» в хранилище ключей (keystore). В браузере будем использовать хранилище формата pkcs12. Его можно создать тем же самым openssl. Команда следующая:

openssl pkcs12 -export -in ssl.crt -inkey privkey1.key -out ssl.p12

Естественно, команду нужно выполнять в директории, в которой находятся файлы сертификата и закрытого ключа (либо прописать их полный путь). Итак, мы получили файл формата *.p12, который содержит в себе пару «закрытый ключ-сертификат» (из первой пары ssl.p12, из второй — trust.p12). Для того, чтобы увидеть какие элементы присутствуют в хранилище, можно воспользоваться стандартными командами openssl, но лучше применить программу Keystore Explorer (http://keystore-explorer.sourceforge.net/). В ней же можно задать необходимые алиасы для идентификации пар «сертификат-закрытый ключ», если их в хранилище несколько.

Разработка клиента на языке программирования (мы реализовывали на Java и C#), обменивающегося сообщениями с веб-сервисами и реализующего аутентификацию клиентов в системе в данной статье не рассматривается. В этот момент было бы хорошо до начала разработки проверить каким-нибудь инструментом, нет ли какого-нибудь подвоха в сертификатах и будет ли работать подписывание должным образом.
Для проверки аутентификации и подписывания будем использовать SoapUI Pro версии 4.5.1. Вначале нам нужно добавить в настройки SoapUI SSL-сертификат для обеспечения защищенного канала с веб-сервисом. В этой версии программы это делается следующим образом: File -> Preferences -> SSL Settings. У меня стоит английская версия, поэтому все термины на английском. В поле KeyStore указываем путь к хранилищу ssl.p12.

В поле KeyStore Password указываем пароль, который мы задавали при создании хранилища. Создать хранилище без пароля не получится и этого делать нельзя, потому что он содержит закрытый ключ. Нажимаем ОК, на этом настройка SSL завершена.

После этого нам необходимо настроить так называемый usernametoken, его подпись и подпись тела сообщения. Подписывание и наличие usernametoken определяются на сервере требованиями безопасности и наличием аутентифкации по токену. О подписывании в SoapUI достаточно подробно написано на сайте самого SoapUI: www.soapui.org/SOAP-and-WSDL/applying-ws-security.html. Где-то повторяясь, где-то добавляя свое, я продолжу свою статью.

WS-Безопасность

Безопасность веб-служб (WS-Security, WSS) является расширением SOAP для применения безопасности к веб-службам. Она является членом веб-службы specifications и была опубликована OASIS.

Протокол специализируется том, как можно обеспечить целостность и конфиденциальность сообщений, и позволяет обмениваться информацией с различными форматами безопасности, такими как язык разметки подтверждения безопасности (SAML), Kerberos и X.509. Основное внимание уделяется использованию XML Signature и XML Encryption для обеспечения сквозной безопасности.

Особенности

WS-Security описывает три основных мс:

Как подписывать сообщения SOAP для обеспечения целостности. Подписанные сообщения также не обеспечивают репарацию.
Как зашифровывать сообщения SOAP для обеспечения конфиденциальности.
Как прикрепить маркеры безопасности для подтверждения личности отправителя.

Специализация допускает различные формы подписи, algorithms кодировки и множественные домены доверия, и открыта для различных моделей token безопасности, таких как:

X.509,
Билеты Kerberos,
Идентификатор пользователя/учетные данные пароля,
Утверждения SAML, и
пользовательские маркеры.

Форматы и семантика токена определяются в соответствующих профильных документах.

WS-Security включает функции безопасности в заголовок сообщения SOAP, работая на уровне приложений.

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

Управление ключами, trust bootstro, федерация и согласование технических деталей (cyphers, formats, algorithms) выходит за рамки WS-Security.

Примеры использования

Сквозная защита

Если требуется промежуточный носитель SOAP и он не является более или менее доверчивым, сообщения должны быть подписаны и опционально зашифрованы. Это может иметь место в случае прокси на уровне приложений в сетевом периметре, который завершает соединения TCP (протокол управления передачей).

Непредставление

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

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

Хотя почти все службы SOAP реализуют HTTP, теоретически могут использоваться другие, такие как JMS или SMTP, в этом случае потребуется сквозная защита.

Повторная передача/общая защита token

Вопросы

При частых обменах сообщениями между поставщиком услуг и потребителем имеет значение избыточность XML SIG и XML ENC. Если требуется сквозная защита, такой протокол, как WS-SecureConversation, может уменьшить перегрузку. Если это достаточно, используйте только кодировку или подпись, так как комбинация обоих значительно медленнее, чем мер-сум отдельных операций. См. раздел Производительность ниже.
Объединение нескольких XML-схем, таких как SOAP, SAML, XML ENC, XML SIG, может вызвать зависимости от различных версий библиотечных функций, таких как канонизация и синтаксический анализ, управление которыми на сервере приложений затруднено.
Если применяется только кодировка/декрипция режима CBC, или если декрипция режима CBC применяется без подтверждения безопасной контрольной суммы (сигнатуры или MAC) перед декриптизацией, то реализация, вероятно, будет уязвима для дополнения атак oracle.

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

WS-Security добавляет значительный избыток в обработку SOAP из-за увеличенного размера сообщения на e, XML и cryptographic обработке, требуя более быстрые CPU и больше памяти и полосы пропускания.

Оценка, проведенная в 2005 году, измерила 25 типов сообщений SOAP различного размера и компитности, обработанных WSS4J как с WS-Security, так и WS-SecureConversation на CPU Pentium 4/ 8 ГГц. Некоторые результаты были следующими:

Кодировка была быстрее, чем подпись.
Кодирование и подписание вместе были в 2 — 7 раз медленнее, чем подписание в одиночку и производили значительно большие документы.
В зависимости от типа сообщения WS-SecureConversation либо не имела никакого значения, либо сократила время обработки вдвое в лучшем случае.
Потребовалось менее 10 секунд, чтобы подписать или зашифровать до array 100 килобайт, но потребовалось около 100 ~ 200, чтобы выполнить операции безопасности для SOAP.

Еще один ориентир в 2006 году привел к такому сопоставлению:

История

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

Первоначально протокол разрабатывался IBM, Microsoft и VeriSign. Их первоначальная специализация была опубликована 5 апреля 2002 года и сопровождалась добавлением 18 августа 2002 года.

В 2002 году в Технический комитет ВСС ОАСИС были представлены два предложения: «Безопасность веб-служб» (WS-Security) и «Дополнение безопасности веб-служб». В результате была опубликована WS-Security:

WS-Security 0 был выпущен 19 апреля 2004 года.
Версия № 1 была выпущена 17 февраля 2006 года.

Стандарт версии 0, опубликованный OASIS, содержал ряд существенных отличий от стандарта, предложенного IBM, Microsoft и VeriSign cons um. Многие системы были разработаны с использованием предложенного стандарта, и различия сделали их несовместимыми с системами, разработанными по стандарту OASIS.

Некоторые называют спецификацию до OASIS «WS-Security Draft 13» или спецификацией ядра безопасности веб-служб. Однако эти имена широко не известны, и сегодня трудно четко определить, использует ли приложение или сервер спецификацию до или после OASIS. Большинство постов форума используют ke ord «WACHord» для ссылки на версию, предшествующую OASIS, потому что она предписывает использование префикса пространства имен «w » XML для URL (и аналогичных URL различных версий).

Связанные со спецификациями

С WS-Security связаны следующие проекты выражений: WS-Federation, WS-Privacy, WS-Test.

Следующие утвержденные спецификации связаны с WS-Security: WS-Policy, WS-SecureConversation, WS-Trust, ID-WSF.

В следующих архитектурах используется WS-Security: TAS3.

Альтернатива

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

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

См. также

Продукты и услуги на основе WS-Security
SAML
Основной профиль безопасности WS-I
X.509
XACML — стандарт для точной динамической авторизации.
Огневая стена XML

Внешние связи

Безопасность веб-служб 1.1.1 (содержит ссылки для загрузки специальных документов.)
Основной профиль безопасности WS-I
Документация по безопасности веб-служб
WSS4J (реализация WS-Security Java от Apache)
Apache Rampart (реализация WS-Security Java от Apache Axis2)
Технологии взаимодействия веб-служб WSIT (WSIT), которые обеспечивают взаимодействие между платформой Java и Windows Communication Foundation (WCF)
Пример безопасности p on ws

Источник: ru.knowledgr.com

Безопасность Web-сервисного взаимодействия

Продолжение. Начало см. PC Week/RE, N 27/2004, с. 20; N 28/2004, с. 19; N 29/2004, с. 18; N 30/2004, с. 20; N 31/2004, с. 22.

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

Сегодня есть несколько наборов спецификаций, говорящих, как решать эти вопросы применительно к Web-сервисам. Первый относится к семейству GXA (Global XML Web Services Architecture), предлагаемому группой компаний, включающей IBM и Microsoft. Он состоит из спецификаций серии WS-*: WS-Security, WS-Trust, WS-SecureConversation, WS-Federation, WS-Policy и пр. Все они проходят утверждение в качестве потенциальных стандартов W3C и OASIS.

Второй набор предлагается группой фирм, более близких к Sun Microsystems и Oracle. К нему относятся две группы стандартов OASIS — SAML и XACML, а также продукция альянса Liberty. Заметим, что в отличие от WS-* это по большей части открытые разработки, т. е. производители ПО могут реализовывать многие из них в своих продуктах бесплатно. Стоит отметить также, что в работе над SAML принимают участие и традиционные противники Sun/Oracle, такие, как те же IBM и Microsoft. Хотя, конечно, роль «первой скрипки» здесь отводится не им.

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

Рис. 1. Стек протоколов обеспечения безопасности Web-сервисов в GXA

Данный раздел обзора «Web-сервисы в корпоративной среде» состоит из нескольких частей — вначале будут рассмотрены средства GXA для обеспечения взаимной безопасности двух взаимодействующих через Web-сервисы сторон, затем — как в GXA организуются политики безопасности и взаимодействие многих сторон, и, наконец, технологии, выходящие под эгидой OASIS и Liberty Alliance.

Web Services Security (WS-Security) и др.

Статус: авторская версия, April 2002.

Авторы: IBM, Microsoft, VerySign.

Опирается на: XML Encryption, XML Signature.

Дополняется: Web Services Security Addendum.

Стандартизация: спецификация лежит в основе SOAP Message Security, имеющего статус рабочего документа OASIS, август 2003.

WS-Security описывает базовый слой для многих других технологий в области безопасности Web-сервисов — а именно то, как обеспечить целостность, конфиденциальность и неподдельность авторства (аутентичность) одного отдельно взятого SOAP-сообщения, передаваемого в рамках уже установленных сессий, контекста и политики безопасности. Она обобщает ряд ранних наработок IBM и Microsoft в этой области, в частности SOAP-SEC, WS-Security and WS-License и пр. В спецификации не говорится о том, как устанавливать контекст сессии, производить аутентификацию сторон, обмен ключами, формировать производные ключи, определять границы доверия доменов. Это задачи других спецификаций GXA. Кроме того, в ней задается только рамочная архитектура — для производства реальных операций она полагается на уже имеющиеся технологии вроде PKI, Kerberos и SSL.

Для достижения сформулированной выше цели спецификация определяет набор расширений SOAP — XML-тегов, позволяющих описывать метаданные о защищенной информации, правила ее размещения внутри SOAP-конверта, правила замещения незашифрованных данных зашифрованными. В ней также задается три основных механизма безопасности: передача жетона безопасности (ЖБ), обеспечение целостности сообщения и его конфиденциальности.

Жетоны безопасности

ЖБ представляют собой некоторый набор утверждений, которые делает отправитель сообщения. Смысл этих утверждений в WS-Security не оговаривается, так как он зависит от конкретной реализации. Утверждениями могут быть имя пользователя, ключ, разрешение на операцию и т. п. Жетон может быть заверен (но не обязательно) цифровой подписью, проверяя которую получатель удостоверяется в том, что отправитель знает необходимый ключ, а стало быть, заслуживает доверия. Важным классом являются утверждения, подписанные авторитетной инстанцией, например сертификаты X.509, задающие связь между некой сущностью (identity) и общедоступным ключом. Обладатель такого сертификата может применять связанный с ним секретный ключ для подписания своих собственных утверждений, которые будут ассоциированы с сущностью через сертификат.

Стороны могут принимать и не подтвержденные подписью ЖБ — в случае, когда уже установлены доверительные отношения между отправителем и получателем, скажем, по защищенному каналу. Особый класс неподтвержденных претензий — доказательства обладания (proof-of-possession), в которых отправитель демонстрирует, что знает определенные сведения, и факт этого знания заинтересованные участники могут проверить. Такой претензией, скажем, может быть комбинация имени пользователя и зашифрованного пароля доступа.

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

Заполнение блока происходит по мере произведения этих операций, что решает проблему влияния более поздних этапов на более ранние. В этом же блоке хранятся двоичные жетоны и сертификаты безопасности (элемент), выданные сторонними системами, например X.509 или Kerberos. Стандарт предусматривает механизм ссылки из текста сообщения на данные в них, в частности для извлечения ключа.

Для этого используется синтаксис аналогичный синтаксису, языка XPath. Имеется способ для извлечения жетонов из внешних источников по ссылке на них (элемент). Неподтвержденные претензии оформляются здесь же — в элементе.

Источник: www.itweek.ru