0

I'm using rampart to secure communication from a webservice client.

Following the specification i defined an asymmetric binding assertion to provide message level security, but I also want to have the communication with webservice over SSL, thus I also defined an appropriate transport binding assertion.

The effect is that my client is able to connect to the webservice over SSL, but in the message that's being sent, there are no signatures - it seems as if the asymmetric binding assertions were ignored.

Is it actually the case? If so - is this a bug in rampart, or is it somehow forbidden by WS Security Policy spec (I haven't found any such information)?

Looking into rampart's MessageBuilder class source I've found this:

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);
}

(the whole code: http://grepcode.com/file/repo1.maven.org/maven2/org.apache.rampart/rampart-core/1.6.2/org/apache/rampart/MessageBuilder.java)

It again makes me think, that one can use only one of security binding and if there are more of them, one is chosen with priority according to above code.

kemot
  • 26
  • 4

2 Answers2

0

I too agree to the point that the specification doesn't say if we can use more than one binding or not (but may be we both have missed it). But you can still use Asymmetric binding for an HTTPS endpoint.

SureshAtt
  • 1,891
  • 2
  • 17
  • 22
0

Finally I think I've solved my problem.

Initially I thought, that the client needs to have the transport binding assertion in it's policy in order to communicate with the webservice over SSL. I also thought, that without such an assertion ramp:sslConfig statements will be ignored.

The truth is, that you don't need transport binding assertion to make it possible to communicate over SSL, you need them to make it required. If there are no such assertions in your client's policy, but the endpoint is requiring SSL connection, the client will still try to establish it and if necessary, look for javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword variables configured in policy's ramp:sslConfig tags, or in other ways (via JVM arguments, or programmatically).

So in my case the solution was to leave the asymmetric binding assertion unchanged and only configure the trustStore, without adding any transport binding assertion.

Still it remains unclear to me why wouldn't rampart let you use the two kinds of assertion in one policy.

kemot
  • 26
  • 4