Jeff Thanks for the feedback. Please can you submit your code as a sample? We will definitely try to fix the bug. I agree rampart should not be causing addressing headers to appear. The reason that the anonymous header is being stripped out is because the WS-A spec says that no reply-to is equivalent to anonymous, so there is a bug in Amazon. However, there is a way in Axis2 to turn this behaviour off.
options.setProperty(AddressingConstants.INCLUDE_OPTIONAL_HEADERS, Boolean.TRUE); So another way to sort that out will be to set that property on the Axis2 MC. Paul On Sun, Jun 8, 2008 at 6:24 AM, Jeff Davis <[EMAIL PROTECTED]> wrote: > Turns out my work-around really didn't solve the problem (because > Axis/Rampart is anticipating a WS-Addressing reply, and since I've stripped > it out downstream, I'd have to add it back manually). > > The crux of the issue is that I cannot figure out how to added this: > > <wsa:ReplyTo><wsa:Address>http://www.w3.org/2005/08/addressing/anonymous > </wsa:Address></wsa:ReplyTo> > > To my WS-Addressing part of my SOAP header. > > I believe it ought to be present, but it's not, as I've confirmed through > TCPMon. I've tried everything I can think of to get it to appear, but thus > far have had no luck. > > Thanks, > > jeff > > On Sat, Jun 7, 2008 at 9:23 PM, Jeff Davis <[EMAIL PROTECTED]> wrote: > >> Maybe it's not a bug but a feature request :-). >> >> I see two issues: >> >> 1) WS-Security automatically adds undesirable WS-Addressing elements (IMO, >> this should only happen when enableAddressing is specified). I don't see >> anything in the WS-Security spec that indicates WS-Addressing is required. I >> don't see a way to turn this behavior off in Synapse, without resorting to a >> workaround such as I demonstrated (i.e., chaining together 2 sequences, >> within one removing the undesirable WS-Addressing elements). >> >> 2) I didn't see a a way to add the ReplyTo WS-Addressing element (and it's >> child node Address) using the header mechanism (or property, for that >> matter). This was the crux of my issue, as, for some reason, Amazon expected >> a ReplyTo. I suspect this is probably easily possible, but just wasn't able >> to figure it out. >> >> Btw, I was able to successfully interact with Amazon's SimpleDB now! I hope >> to writeup a blog entry on my findings (I am actually also writing the book >> called Open Source SOA from Manning, and I am including a big chapter on >> Synapse, which I am a huge fan of). >> >> To be honest, a lot of this WS-Security stuff is rather new to me, so I'm >> feverishly trying to get a handle on it (the Manning book SOA Security has >> been a big help). I have used PasswordDigest mechanism a lot, but not that >> signing with x509 certs as much. >> >> jeff >> >> >> On Sat, Jun 7, 2008 at 8:42 PM, Ruwan Linton <[EMAIL PROTECTED]> >> wrote: >> >>> Hi Jeff, >>> >>> What is the bug from your POV? I am sorry, I don't see a bug here..... >>> >>> Well you could go ahead and file a JIRA so that we can evaluate what is >>> the >>> issue that you have faced and see whether is there something wrong with >>> Synapse, but I assume this is rather a configuration error. >>> >>> Thanks, >>> Ruwan >>> >>> >>> On Sun, Jun 8, 2008 at 7:45 AM, Jeff Davis <[EMAIL PROTECTED]> wrote: >>> >>> > As a follow-up, I was running it through tcpmon, which is why it had the >>> > strange address. >>> > >>> > Yes, I am running the latest 1.2 build from the URL provided me last >>> > Thursday, I believe. >>> > >>> > Should I submit this is a bug? >>> > >>> > On Sat, Jun 7, 2008 at 8:11 PM, Ruwan Linton <[EMAIL PROTECTED]> >>> > wrote: >>> > >>> > > Hi Jeff, >>> > > >>> > > If you enable addressing to the outbound message then synapse should >>> be >>> > > sending the ReplyTo header as appropriate. May be amazon is not >>> accepting >>> > > anonymous ReplyTo headers, so assuming that you are using the 1.2 >>> build >>> > > here >>> > > is the proposed solution to this; >>> > > >>> > > <definitions xmlns="http://ws.apache.org/ns/synapse";> >>> > > <localEntry key="sec_policy" >>> > > src="file:repository/conf/sample/resources/policy/amazon.xml"/> >>> > > >>> > > <in> >>> > > <send> >>> > > <endpoint name="secure"> >>> > > <address uri="http://localhost:8086";> >>> > > <enableSec policy="sec_policy"/> >>> > > <enableAddressing separateListener="true"/> >>> > > </address> >>> > > </endpoint> >>> > > </send> >>> > > </in> >>> > > <out> >>> > > <header name="wsse:Security" action="remove" xmlns:wsse=" >>> > > http://www.w3.org/2005/08/addressing"/> >>> > > <send/> >>> > > </out> >>> > > </definitions> >>> > > >>> > > The above configuration should work, but please note that you need to >>> > > change >>> > > the address uri of the endpoint in the above configuration from " >>> > > http://localhost:8086"; to "AMAZON_URL" >>> > > >>> > > If this is not working could you please attach the TCPMon out put of >>> the >>> > > outbound message which is going to AMAZON (after changing important >>> > > information) and the message received from AMAZON. If you don't want >>> to >>> > > post >>> > > it publicly you may send it to me (mailto:[EMAIL PROTECTED] < >>> [EMAIL PROTECTED] >>> > >) >>> > > >>> > > Thanks, >>> > > Ruwan >>> > > >>> > > On Sun, Jun 8, 2008 at 7:01 AM, 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=""/> >>> > > > <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 >>> > > > > >>> > > > >>> > > >>> > > >>> > > >>> > > -- >>> > > Ruwan Linton >>> > > http://www.wso2.org - "Oxygenating the Web Services Platform" >>> > > >>> > >>> >>> >>> >>> -- >>> Ruwan Linton >>> http://www.wso2.org - "Oxygenating the Web Services Platform" >>> >> >> > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
