Hi Nandana, It's using http. Is there no way enforce https, that is not to send the message at all if no https protocol is used? I can run a service over https without specifying a HttpsToken in the policy so I'm puzzled why there is a HttpsToken example with Rampart.
I have a situation where the client needs to connect to multiple implementations of the same service wsdl. I won't have control over these services but I need to ensure the confidentiality of certain messages sent to these services. I'm trying to determine what the best strategy is, whether to use transport level or message level security, while keeping it as simple as possible - I don't want the client or service sides to have to manage many keys/certificates. By the way, thanks for your reply to my other question today. Regards, Alan. On 10/31/07, Nandana Mihindukulasooriya <[EMAIL PROTECTED]> wrote: > HI Alan, > can you post the what you capture with the TCPMon. I think in > the earlier post you mentioned, the header says, > > > POST /axis2/services/sample02 HTTP/1.1 > > > I think this gives us a clue. Here I think HTTP protocol is used not the > HTTPS. Even though you have Transport binding with HTTP Token if > you use the endpoint, > http://xxxx/ axis2/services/xxx rather than > https://xxxx/axis2/services/ xxx you are going through a unsecured > channel, so soap messages can be read as plain text. > > So can you please check that you have not mistyped http for https. > > Regards, > Nandana > > > On 10/31/07, Alan Sunley <[EMAIL PROTECTED]> wrote: > > > > Greetings, > > > > Is there a way to enforce transport level encryption with Rampart? I'm > > experimenting with Policy example 01 using the TransportBinding and > > HttpsToken assertions but I'm noticing that the soap messages are not > > being encrypted when capturing them with TCPMon. > > > > There was a similar post several months ago, without a specific > > answer: > > http://www.mail-archive.com/[email protected]/msg00379.html > > > > Can I assume this is an error with the configuration and is not > > expected behavior? > > > > Regards, > > Alan. > > >
