Actually, I was able to get beyond this issue using the following definition:
On Sat, Jun 7, 2008 at 7:31 PM, Jeff Davis <[EMAIL PROTECTED]> wrote: > I did a little research, and I haven't seen anything in the standard that > indicates WS-Security requires WS-Addressing. Unfortunately, it doesn't > appear as though setting the header has any impact (further, if it did, the > ReplyTo has a child element for the Address, so not sure how that would be > added). Here's my configuration: > > <definitions xmlns="http://ws.apache.org/ns/synapse";> > <localEntry key="sec_policy" > src="file:repository/conf/sample/resources/policy/amazon.xml"/> > > <in> > <header name="ReplyTo" action="set" value=""/><definitions xmlns=" > http://ws.apache.org/ns/synapse"; xmlns:wsa=" > http://www.w3.org/2005/08/addressing";> > <localEntry key="sec_policy" > src="file:repository/conf/sample/resources/policy/amazon.xml"/> > > <sequence name="amazonFirstPassIn" trace="enable"> > <send> > <endpoint name="secure"> > <address uri=" > http://localhost:8280/soap/amazonNoAddressing";> > <enableSec policy="sec_policy"/> > </address> > </endpoint> > </send> > </sequence> > > <sequence name="amazonSecondPassIn" trace="enable"> > <send> > <endpoint name="secure"> > <address uri="http://localhost:8086";> > > </address> > </endpoint> > </send> > </sequence> > > <sequence name="amazonFirstPassOut" trace="enable"> > <header name="wsa:Address" action="remove" > xmlns:wsse="http://www.w3.org/2005/08/addressing"/> > <send/> > </sequence> > > <sequence name="amazonSecondPassOut" trace="enable"> > <header name="wsse:Security" action="remove" > xmlns:wsse=" > http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd > "/> > <send/> > </sequence> > > <proxy name="amazon" transports="http, https"> > <target inSequence="amazonFirstPassIn" > outSequence="amazonFirstPassOut"/> > </proxy> > > <proxy name="amazonNoAddressing" transports="http, https"> > <target inSequence="amazonSecondPassIn" > outSequence="amazonSecondPassOut"/> > </proxy> > > </definitions> > To be honest, I'm not entirely sure I understand the sequence why this works, but I'm glad it does :-) > <send> > <endpoint name="secure"> > <address uri="http://localhost:8086";> > <enableSec policy="sec_policy"/> > <enableAddressing/> > </address> > </endpoint> > </send> > </in> > <out> > <send/> > </out> > </definitions> > > In lieu of the above header, I also tried: > > <header name="wsse:Security" action="remove" > xmlns:wsse="http://www.w3.org/2005/08/addressing"/> > > (I also tried removing the <enableAddressing/> node for each test). > > To recap my issue, it seems as though Amazon AWS (at least for SimpleDB > service) requires the ReplyTo WS-Addressing element, if WS-Addressing is > used. I haven't found a way to remove WS-Addressing generated automatically > by Synapse when WS-Security is used, and I haven't figure out how to add > ReplyTo (and it's child Address node) to the outbound message. > > Anyone have any work-arounds? Maybe I'll try chaining together some things > to see if I can devise something. > > Thanks, > > jeff > > > > On Sat, Jun 7, 2008 at 9:25 AM, Asankha C. Perera <[EMAIL PROTECTED]> > wrote: > >> Hi Jeff >> >>> To be honest, I'm not entirely certain how to add it in the Header >>> mediator, >>> as you allude to. I did try various permutations of using the property >>> and >>> header nodes within the <in>, but nothing ever appeared. >>> >>> >> I am sorry.. I had made a mistake in my reply earlier.. to set the ReplyTo >> header to something, you will use "<header name="ReplyTo" value="..."/> >> format.. If you are familiar with using TCPMon, you can place it between >> your service and Amazon and route the message through it to get a trace of >> the messages. This will help you and us to solve any problems. >> >>> Obviously, Amazon's service is not entirely compliant with the >>> WS-Security >>> standards. Even in their section under WS-Security SOAP, they state that >>> "if >>> you're using WS-Addressing, we recommend you also sign the Action and To >>> header elements" (I haven't figured out how to do that yet, but I'll dig >>> into that). >>> >>> >> If you are ok to share your configuration/scenario with us or let us try >> some simple sample to reproduce the issue you are facing, one of the >> developers would be able to tell you exactly whats wrong, and what you could >> do to get past the problem >> >> asankha >> > >
