Невозможно ли иметь безопасность на уровне транспортного уровня и уровень безопасности сообщений в валу? Зачем?

Question

Я использую rampart для обеспечения связи с клиентом webservice.

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

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

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

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

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)

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

Answer 1

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

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

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

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

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

Answer 2

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