Невозможно ли иметь в валу как безопасность на транспортном уровне, так и безопасность на уровне сообщений? Почему?

Я использую Rampart для защиты связи от клиента веб-сервиса.

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

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

Так ли это на самом деле? Если да, то является ли это ошибкой в ​​валу или это как-то запрещено спецификацией WS Security Policy (такой информации я не нашел)?

Глядя на источник класса MessageBuilder вала, я нашел это:

if(rpd.isTransportBinding()) {
   log.debug("Building transport binding");
   TransportBindingBuilder building = new TransportBindingBuilder();
   building.build(rmd);
} else if(rpd.isSymmetricBinding()) {
   log.debug("Building SymmetricBinding");
   SymmetricBindingBuilder builder = new SymmetricBindingBuilder();
   builder.build(rmd);
} else {
   AsymmetricBindingBuilder builder = new AsymmetricBindingBuilder();
   builder.build(rmd);
}

(весь код: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.rampart/rampart-core/1.6.2/org/apache/rampart/MessageBuilder.java< /а>)

Это снова наводит меня на мысль, что можно использовать только одну привязку безопасности, и если их больше, то выбирается одна с приоритетом в соответствии с приведенным выше кодом.


java ssl web-services ws-security rampart
person kemot    schedule 23.08.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я тоже согласен с тем, что в спецификации не сказано, можем ли мы использовать более одной привязки или нет (но, возможно, мы оба пропустили это). Но вы по-прежнему можете использовать асимметричную привязку для конечной точки HTTPS.

person SureshAtt    schedule 02.09.2013

arrow_upward
0
arrow_downward

Наконец, я думаю, что решил свою проблему.

Первоначально я думал, что клиент должен иметь в своей политике утверждение привязки транспорта, чтобы общаться с веб-сервисом через SSL. Я также подумал, что без такого утверждения ramp:sslConfig операторы будут проигнорированы.

Правда в том, что вам не нужно утверждение привязки транспорта, чтобы сделать его возможным для связи через SSL, они нужны вам, чтобы сделать его требуемым. Если таких утверждений в политике вашего клиента нет, но конечная точка требует SSL-подключения, клиент все равно попытается его установить и при необходимости искать переменные javax.net.ssl.trustStore и javax.net.ssl.trustStorePassword, настроенные в тегах ramp:sslConfig политики, или другими способами (через JVM аргументы или программно).

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

Тем не менее, мне остается непонятным, почему вал не позволяет вам использовать два вида утверждений в одной политике.

person kemot    schedule 03.09.2013