Final Steps for Security Optimization with Web Services - Configuring the Service for Routing

1. Open policyCache.config in the RoutingService project and locate the <endpoint> elements within policyDocument/mappings.
   
2. Change the value of the uri attribute on each <endpoint> element to contain the same values that you used in the <appSettings> section in the previous section.
   
   <policyDocument
   xmlns= "http://schemas.
   microsoft.com/wse/2003/06/
   Policy">
     <mappings xmlns:wse="http://schemas.
   microsoft.com/wse/2003/06
   /Policy">
       <endpoint uri="http://localhost/router/
   submit.ashx"> 
         <defaultOperation>
         ...
   
   Note: this change is necessary because the policy mapping is driven by the value of the wsa:To header, which in this case contains the original destination before the routing takes place.
   
   Note: The policyCache.config file may have been built with a different machine name for the wse:Role elements for authorization checking. If this is the case, please check each of the wse:Role elements and confirm that the correct machine name has been supplied.
   
   
3. Right click ViewInvoices.asmx and select View Code. 
   
4. Add a using statement to the top of the file for Microsoft.Web.Services2. Messaging:
   
   ...
   Imports Microsoft.Web.Services2. Messaging
   ... 
   
5. Add a SoapActor attribute to the ViewInvoices class specifying the router URL that the message will travel through, as illustrated here:
   
   <WebService([Namespace]:="http://example.
   org/invoices"),
    SoapActor("http://localhost/router/view.
   ashx")> 
   Public Class ViewInvoices
      ...
   End Class
   
   Note: WSE checks the value of the URL and the wsa:To header and when they don't match (like in this case) it throws an exception. The [SoapActor] attribute indicates that it may pass through an intermediary node.
   
   
6. Repeat the last two steps for each of the .asmx endpoints in the RouterService project (ApproveInvoice.asmx, PayInvoice.asmx, and SubmitInvoice.asmx).
   
7. Build the solution. 
   
8. Run the client and verify that everything works going through the intermediary router.
   
   Note: in this example, the SOAP messages travel securely (with security tokens, signatures, and encrypted data found in the message) through the intermediary router and onto the ultimate receiver. This illustrates the end-
   to-end security model offered by the WS-Security framework.

Lab Summary

WSE 2.0 provides a framework for securing Web services either through code or through declarative policy files. The exercises in this lab showed you how to secure your Web services with authentication, integrity, and privacy through the built-in implementations of today's industry standard specifications.

Comments On: Final Steps for Security Optimization with Web Services

· We hope you found this lab from MSDN Virtual Labs to be entertaining and...   >>> Post your comment now!