Tracing capablities in WSE2

WSE 2.0 was released at TechEd today. Congratulations to the WSE team with Rebecca Dias, Keith Ballinger and the rest of the WSE Team. Version 2 comes with support for WS-Addressing, WS-Security, WS-Policy and a few other WS-* standards.

 

WS-Addressing moves the destination URL of the message into the message to enable routing and scenarios where messages are delivered over multiple protocols. Before WS-Addressing the URL of the destination was only available in the protocol part of the message. Is you were sending a SOAP message over HTTP, the URL was stored in the HTTP part of the message. You had no access to the URL from within your SOAP processor – unless your Web server vendor chose to give you access to the HTTP headers.

 

Now with WS-Addressing built into WSE, the Web service platform can actually determine if a message was indeed intended for the service that received it because WSE adds the <to> element to the header of the SOAP message:

 

      <wsa:To xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">

http://MyServer/MyService/Service.asmx</wsa:To>

 

WSE is actually being smart about the header and rejects messages where the destination in the <wsa:To> header and the URL in the HTTP header do not match.

 

One unfortunate consequence of this behavior is that you cannot use transparent tracing tools like tcpTrace and MSSoapT for message debugging. These tools act like an intermediary receiver and they do cause the URLs in the <To> header and in the HTTP header to not match. If you tried, the WSE web service returns a nice, descriptive fault telling you exactly what’s going on:

 

Microsoft.Web.Services2.Addressing.AddressingFault: Destination Unreachable ---&gt; System.Exception:

WSE816:

The &lt;To&gt; header must match the value of an incoming message's HTTP Request Url if the soap receiver does not have an actor name.

The &lt;To&gt; header received contained "http://localhost:8080/WSEWebService/Service1.asmx"

while the HTTP Request Url was "http://localhost/WSEWebService/Service1.asmx".

 

You could fix the problem by modifing the WSE server code that is sending the message to tell the receiver about the URL of the tracing tool by adding a SoapActor attribute to the service.

 

<System.Web.Services.WebService(Namespace:="http://tempuri.org/WSEWebService/Service1"), _

SoapActor("http://localhost:8080/WSEWebService/Service1.asmx")> _

Public Class Service1

 

But that defeats the purpose of a transparent tracing tool and in many cases it may just not be feasible to modify the service code for troubleshooting purposes.

 

The good new is though that you no longer need tracing tools when you need to debug SOAP messages processed by a WSE service. You simple configure WSE to trace the output for you using the WSE 2.0 Settings tool. On the “Diagnostics” tab of the tool you will find the two sections “Message Tracing” and “Policy Tracing”. When you check the “Message Tracing” check boxes, WSE will write all processed messages – sent and received – to a trace file.

 

The “Policy Tracing” setting is even better though. With the powerful, declarative, policy based model, WSE does a lot of message processing with no coding involved. For example WSE will reject SOAP messages that violate the policy configuration. If the policy requires messages to be signed with a particular security token, but the message contains the wrong signature, WSE will simply return a policy violation fault. Unfortunately, the error message is not quite as descriptive as it was for the missing SoapActor attribute.

 

The policy trace output is extremely handy in this scenario, because it will tell you which policy was violated. The result of the policy enforcement step for each received message is written as a <message> element to the policy trace file:

 

  <wset:message to="http://localhost/MyWebMethodsWse/Service1.asmx" from="http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous" action="http://example.org/mortgage-tools/CalculateMortgage" messageId="uuid:5334eabc-58e7-4220-984e-35cc2c5309ce" appDomain="/LM/W3SVC/1/Root/MyWebMethodsWse-16-127289102890960160" time="2004-05-12T22:52:19.7795824-05:00">

    <wset:verify qname="wsp:Policy" wsu:Id="#Sign-Username-2" usage="Required" satisfied="false">

      <wset:verify qname="wsp:MessagePredicate" usage="Required" satisfied="true" />

      <wset:verify qname="wssp:Integrity" usage="Required" satisfied="false" />

    </wset:verify>

  </wset:message>

 

The example above shows that the required Integrity assertion of a policy named “Sign-Username-2” failed – the satisfied attribute for this assertion is set to false. Now you can check the policyCache.webinfo file for the policy with a wsu:Id attribute set to "Sign-Username-2":

 

<policyDocument xmlns="http://schemas.microsoft.com/wse/2003/06/Policy">

  <policies …>

    <wsp:Policy wsu:Id="Sign-Username-2">

      <wssp:Integrity wsp:Usage="wsp:Required">

 

 

and verify what Integrity claims the policy required. Finally, you can cross-check the claims against the received message and you can determine the cause of the assertion failure. I really like the fact that tracing is now a framework feature. It seems to be the Microsoft way to handle this, more on that soon.

13 Comments

  • Christian,



    Your approach works also, but again, it's not transparent. I have to change code to enable tracing.



    Mark Taulty's trace tool seems to be the best way to go for debugging messages.

  • Hi

    Currently I am facing the same problem for x-5-9 certificates.I am sending request to service but response gives an error.

    request Header is as shown below :

    &lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?&gt;

    - &lt;soap:Envelope xmlns:soap=&quot;<a target="_new" href="http://schemas.xmlsoap.org/soap/envelope/&quot;">http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:xsi=&quot;<a target="_new" href="http://www.w3.org/2001/XMLSchema-instance&quot;">http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:xsd=&quot;<a target="_new" href="http://www.w3.org/2001/XMLSchema&quot;">http://www.w3.org/2001/XMLSchema&quot; xmlns:wsa=&quot;<a target="_new" href="http://schemas.xmlsoap.org/ws/2004/03/addressing&quot;">http://schemas.xmlsoap.org/ws/2004/03/addressing&quot; xmlns:wsse=&quot;<a target="_new" href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot;">http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; xmlns:wsu=&quot;<a target="_new" href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot;&gt;">http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot;&gt;

    - &lt;soap:Header&gt;

    &lt;wsa:Action&gt;http://tempuri.org/Method1&lt;/wsa:Action&gt;

    &lt;wsa:MessageID&gt;uuid:058a8965-3bd3-4e29-8c2b-f96f74ccef7d&lt;/wsa:MessageID&gt;

    - &lt;wsa:ReplyTo&gt;

    &lt;wsa:Address&gt;http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous&lt;/wsa:Address&gt;

    &lt;/wsa:ReplyTo&gt;

    &lt;wsa:To&gt;http://localhost:7080/AllWebService/Basic/testMe.asmx&lt;/wsa:To&gt;

    - &lt;wsse:Security soap:mustUnderstand=&quot;1&quot;&gt;

    - &lt;wsu:Timestamp wsu:Id=&quot;Timestamp-960109fc-9ebf-44cb-9242-fad05f38d843&quot;&gt;

    &lt;wsu:Created&gt;2004-07-30T06:25:05Z&lt;/wsu:Created&gt;

    &lt;wsu:Expires&gt;2004-07-30T06:30:05Z&lt;/wsu:Expires&gt;

    &lt;/wsu:Timestamp&gt;

    &lt;wsse:BinarySecurityToken ValueType=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3&quot; EncodingType=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary&quot; xmlns:wsu=&quot;http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot; wsu:Id=&quot;SecurityToken-202673c0-3510-49b9-8907-2320b50c75d2&quot;&gt;MIIBtzCCAWGgAwIBAgIQ9Qo/f846YI1KbFmOVEtOzDANBgkqhkiG9w0BAQQFADAWMRQwEgYDVQQDEwtSb290IEFnZW5jeTAeFw0wNDA3MTkwNTEwMDJaFw0zOTEyMzEyMzU5NTlaMBIxEDAOBgNVBAMTB3NhY2hpbjEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMnfeeeGTQ21+6s5IWrCd00T8VqgIowSNsDvqsGc4XpXnF5xRgLmNuheQ4K+NrVpR4KBSZapj91NFxkeBddxCmi2vZ+zmB2H/6lcvurJX3UafJjg/Y9bizbgcW4SIvA9bOqH/6+7GvKdQm2ycD4xM4MrEj9/YXmQV5H1Bve7WJw3AgMBAAGjSzBJMEcGA1UdAQRAMD6AEBLkCS0GHR1PAI1hIdwWZGOhGDAWMRQwEgYDVQQDEwtSb290IEFnZW5jeYIQBjdsAKoAZIoRz7jUqlw19DANBgkqhkiG9w0BAQQFAANBAH9VouFs/n1GwA8fhz/CyAEK7gxQUCZhyr2oDkIlPEXKQnydvw0at0vUeNL3L/NCiZNP5sRe15fYX36qVu2QqPU=&lt;/wsse:BinarySecurityToken&gt;

    &lt;/wsse:Security&gt;

    &lt;/soap:Header&gt;

    - &lt;soap:Body&gt;

    &lt;Method1 xmlns=&quot;http://tempuri.org/&quot; /&gt;

    &lt;/soap:Body&gt;

    &lt;/soap:Envelope&gt;



    While Response is as shown :



    &lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?&gt;

    - &lt;soap:Envelope xmlns:soap=&quot;<a target="_new" href="http://schemas.xmlsoap.org/soap/envelope/&quot;">http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:xsi=&quot;<a target="_new" href="http://www.w3.org/2001/XMLSchema-instance&quot;">http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:xsd=&quot;<a target="_new" href="http://www.w3.org/2001/XMLSchema&quot;">http://www.w3.org/2001/XMLSchema&quot; xmlns:wsa=&quot;<a target="_new" href="http://schemas.xmlsoap.org/ws/2004/03/addressing&quot;">http://schemas.xmlsoap.org/ws/2004/03/addressing&quot; xmlns:wsse=&quot;<a target="_new" href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot;">http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd&quot; xmlns:wsu=&quot;<a target="_new" href="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot;&gt;">http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd&quot;&gt;

    - &lt;soap:Header&gt;

    &lt;wsa:Action&gt;http://schemas.xmlsoap.org/ws/2004/03/addressing/fault&lt;/wsa:Action&gt;

    &lt;wsa:MessageID&gt;uuid:d8dba19b-72ec-4c63-b933-5c2f8ea3d9ec&lt;/wsa:MessageID&gt;

    &lt;wsa:RelatesTo&gt;uuid:058a8965-3bd3-4e29-8c2b-f96f74ccef7d&lt;/wsa:RelatesTo&gt;

    &lt;wsa:To&gt;http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous&lt;/wsa:To&gt;

    - &lt;wsse:Security&gt;

    - &lt;wsu:Timestamp wsu:Id=&quot;Timestamp-0a6135fa-664d-4271-a3c4-0066369b13f6&quot;&gt;

    &lt;wsu:Created&gt;2004-07-30T06:25:05Z&lt;/wsu:Created&gt;

    &lt;wsu:Expires&gt;2004-07-30T06:30:05Z&lt;/wsu:Expires&gt;

    &lt;/wsu:Timestamp&gt;

    &lt;/wsse:Security&gt;

    &lt;/soap:Header&gt;

    - &lt;soap:Body&gt;

    - &lt;soap:Fault&gt;

    &lt;faultcode xmlns:q0=&quot;<a target="_new" href="http://schemas.xmlsoap.org/ws/2004/03/addressing&quot;">http://schemas.xmlsoap.org/ws/2004/03/addressing&quot;&gt;q0:DestinationUnreachable&lt;/faultcode&gt;

    &lt;faultstring&gt;Microsoft.Web.Services2.Addressing.AddressingFault: Destination Unreachable ---&gt; System.Exception: WSE816: The &lt;To&gt; header must match the value of an incoming message's HTTP Request Url if the soap receiver does not have an actor name. The &lt;To&gt; header received contained &quot;http://localhost:7080/AllWebService/Basic/testMe.asmx&quot; while the HTTP Request Url was &quot;http://localhost/AllWebService/Basic/testMe.asmx&quot;. --- End of inner exception stack trace --- at Microsoft.Web.Services2.WebServicesExtension.AfterDeserialize(SoapMessage message) at Microsoft.Web.Services2.WebServicesExtension.ProcessMessage(SoapMessage message) at System.Web.Services.Protocols.SoapMessage.RunExtensions(SoapExtension[] extensions) at System.Web.Services.Protocols.SoapServerProtocol.CreateServerInstance() at System.Web.Services.Protocols.WebServiceHandler.Invoke() at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()&lt;/faultstring&gt;

    &lt;/soap:Fault&gt;

    &lt;/soap:Body&gt;

    &lt;/soap:Envelope&gt;





    Will U help to solve this problem.

    Pls response..

    Sachin

  • Are you using some tracing tool or a proxy server that intercepts and forwards the web requests? The error message states that you are sending the soap request to port 7080, but the web service is listening on port 80.

    Because the WSE proxy generated a &lt;To&gt; heading in the message saying that the request was sent to a service listening on port 80, but on the server WSE is listening on port 80, the WSE runtime rejects the message and send you the error.



    What's the motivation for that intermediary? If it's for tracing only, make sure you check out Mike Taulty's tracing tool.



    HTH,

    Christoph

  • HI Christoph; Any way to rule out above problem by putting entries in web.config on server side?


    -Gangs

  • KMtTTo I think this is a real great blog article.Thanks Again. Great.

  • sNpJRn A round of applause for your blog post.Really looking forward to read more. Fantastic.

  • 5D9Btb I am so grateful for your article.Really looking forward to read more. Keep writing.

  • jbuO46 Hey, thanks for the blog.Thanks Again. Much obliged.

  • 16sMAR Fantastic blog post.Really thank you! Fantastic.

  • biSQne Major thankies for the blog article. Much obliged.

  • gmilit Great, thanks for sharing this blog article. Really Great.

  • HguKq2 Major thanks for the blog.Thanks Again. Will read on...

  • QN9zaU Awesome article post.Thanks Again. Really Cool.

Comments have been disabled for this content.