| Zach's profileZach BonhamPhotosBlogLists |  Tools  Help |
|
August 19 Of WSE, F5 and the SoapActorAttributeThis is one of those situations where expectations and reality just don't quite meet.
Background
Partner facing web services that use an F5 BIG-IP load balancing device, digital x.509 certificates hosted on the server, and a pool of web servers to handle the actual requests. Client establishes a secure SSL connection on port 443 to the F5, which then proxies the request to a web server on port 80. The connection is only secured with SSL up to the hardware load balancer
During the development of a partner facing set of web services, everything was going smoothly until it came time to access them across the internet. Up to this point, we've been developing, testing and deploying within our network. Which is not to say that we didn't make sure we could use the F5 to load balance across our development servers, and I don't mean to say that we didn't have tests using SSL (direct to web server) connections. What we didn't have is a load balanced SSL site on our development network, otherwise we would have caught the problem earlier!
The Problem
Turns out, when you've got a client making an 'https' request and then the load balancer proxing a standard 'http' request to your web server, you're using Web Service Extensions (WSE), your WSE enabled service is going to throw an exception in its receive filter pipeline as
System.Web.Services.Protocols.SoapException: SOAP-Fault code:http://schemas.xmlsoap.org/ws/2004/08/addressing:DestinationUnreachable
Message: Microsoft.Web.Services3.Addressing.AddressingFault: Destination Unreachable ---> System.Exception: WSE846: The <wsa:To> header must match the actor URI value of the web service. The actor URI value can be explicitly specified using SoapActorAttribute on the ASMX class. In the absence of the attribute, the actor URI is assumed to be equal to the HTTP Request Url of the incoming message. The <To> header received contained https://bogus/test/public-cn/ItemMasterService.asmx while the receiver is expecting http://bogus/test/public-cn/ItemMasterService.asmx. --- End of inner exception stack trace ---
What to do? The wsa:To is setup using its default behavior and you don't want your client to have to 'hack' their way around to setup the request correctly.
We also briefly considered using the scripting capabilities of the F5 to modifying the payload on the way in to fixup the request, whic seems like another hack, but now it involves not the client, but another team.
Finally, looked up the SoapActorAttribute. Looks like we can turn off the verification of WSE that the wsa:To and the original requesting URI match, and keep the dirty little secret within our team. So this was the hack that was chosen. I'm not entirely sure its a hack, but it seems like I've lost some of the functionality of why I chose WSE in the first place.
From MSDN:
"When a Web service is hosted in a Web farm that uses one URI for the load balancer and a different URI for the individual computers in the Web farm, disabling this check is necessary. For example, when SSL is used to access a Web farm, the URI to access the hardware load balancer typically uses the https scheme, whereas the URIs for the individual members of the Web farm use a URI with an http scheme. In this scenario, apply a SoapActorAttribute attribute to the class implementing the Web service and set the Actor property to *. "
The Fix
Simply appended the attribute to our sevices:
[SoapActor("*")]
..and everything magically began working as expected. Comments (6)
TrackbacksThe trackback URL for this entry is: http://zachbonham.spaces.live.com/blog/cns!796D9CBF83641CEF!394.trak Weblogs that reference this entry
|
|
|
