Hi Jeff, Nice to hear that you got it to work :-) ; See my comments in-line...
On Mon, Jun 9, 2008 at 3:59 AM, Jeff Davis <[EMAIL PROTECTED]> wrote: > I'm sure you guys are sick of hearing from me by now :-). > > That change you guys had suggested corrected the issue with the ReplyTo > being generated. That's the good news! I do have one last issue (I am so > close to getting everything entirely working). I believe this is also do to > a buggy Amazon WS implementation. That is, there response doesn't contain > any WSSE security stuff in their response. Here's an example of what I > receive from them: Jeff, I guess this is accepted and known as *message level policies*, so the in-message contains a security policy and the out-message does not. > > > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/ > "> > <soapenv:Header> > <wsa:RelatesTo xmlns:wsa="http://www.w3.org/2005/08/addressing"; > > >urn:uuid:A25F54392EB2D8B86E1212962691230477001-1880534923</wsa:RelatesTo> > <wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing"; > >http://www.w3.org/2005/08/addressing/anonymous</wsa:To> > <wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing > ">ListDomains:Response</wsa:Action> > <wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing"; > >urn:uuid:337570bf-2dd7-4e5d-a578-3a57800ec5e4</wsa:MessageID> > </soapenv:Header> > <soapenv:Body> > <ListDomainsResponse xmlns=" > http://sdb.amazonaws.com/doc/2007-11-07/ > "> > <ListDomainsResult> > <DomainName>test</DomainName> > </ListDomainsResult> > <ResponseMetadata> > <RequestId>337570bf-2dd7-4e5d-a578-3a57800ec5e4</RequestId> > <BoxUsage>0.0000071759</BoxUsage> > </ResponseMetadata> > </ListDomainsResponse> > </soapenv:Body> > </soapenv:Envelope> > > > Apparently Rampart anticipates a WS-Security in the response, but as you > can > see, it's not present. I've tried identifying where in the WS-Policy > configuration I can have that turned off, but I don't see anything. > > I could probably add it myself, but not sure how to do this without > resorting to a custom mediator of some sort, since I don't believe XSTL or > Script mediators have access to the SOAP header in the response? Actually both the Script mediator and the XSLT mediator has the access to SOAP headers, but I don't see none of these to be fitting to your problem because Rampart is going to throw an error upon receiving this message if you engage security to the outbound message. By the way, what is your new configuration. Are you forwarding the message from the client without modifying the security headers? Or do you engage security on the outbound message on the endpoint? If it is the former, we should be able to use a custom mediator, but if that is the later we need a small improvement on the Synapse side, which Asankha has pointed. (Message level policies for the outbound messages on endpoint level) > > > Upon conclusion of this whole exercise, I will get something written up for > others who wish to use Synapse in conjunction with Amazon's web services. This is perfect. I will help you through to get this working. If we need to implement message level policies for endpoints I can work on that soon so that we can include that on the point release that we are planing soon after the 1.2 with AXIOM improvements. Thanks, Ruwan > As > you know, AWS is becoming very popular, especially EC2 and S3. My hope is > to use Synapse as proxy/mediator that will receive outbound, non > WS-Security > calls to AWS add on the appropriate WS-Security, then forward to AWS. > > jeff > > On Sun, Jun 8, 2008 at 12:35 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote: > > > Ruwan > > > > I think its enough to set the anonymous one as long as we send it. > > That might just fix everything. > > > > Paul > > > > On Sun, Jun 8, 2008 at 2:22 PM, Ruwan Linton <[EMAIL PROTECTED]> > > wrote: > > > Hi Jeff and Paul, > > > > > > I was able to reproduce the issue, basically whatever we specify as the > > > ReplyTo header Addressing module changes it to anonymous for the > outbound > > > message and neglects sending it. So setting the ReplyTo header is not > > > effective for the moment. Jeff, could you please file a JIRA for this. > At > > > the same time I had a look at what Paul proposed and it seems to work > but > > > still it is just the anonymous address but not the one we set. You > could > > use > > > the property mediator at the axis2-client scope to set this property as > > > follows to include the anonymous header; > > > > > > <syn:property name="includeOptionalHeaders" value="true" > > > scope="axis2-client"/> > > > > > > Or if you use separateListener attribute to true with the > > enableAddressing > > > tag then you can see the non anonymous ReplyTo header is being sent to > > the > > > service. > > > > > > I will look for a solution to this issue ASAP. Thanks Jeff for pointing > > this > > > out. > > > > > > Thanks, > > > Ruwan > > > > > > On Sun, Jun 8, 2008 at 1:40 PM, Paul Fremantle <[EMAIL PROTECTED]> > wrote: > > > > > >> 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 > > >> > > > > > > > > > > > > -- > > > 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 > > > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform"
