Final Steps for Security Optimization with Web Services

Exercise 4 Optimizing Security with Secure Conversation

Scenario

One of the issues with using certificates to sign and encrypt messages is that the asymmetric algorithms (based on public/private keys) are very expensive. When a sender and a receiver are going to exchange multiple messages over a period of time, it would be more efficient to derive a session key from a security context that can be used over and over again for a period of time, thus allowing for more efficient symmetric security algorithms to be used. WS-Trust and WS-SecureConversation are two specifications that outline how to implement this concept.

WSE 2.0 provides support for WS-Trust and WS-SecureConversation and it makes it very easy to get it up and running through policy statements. In this exercise, you're going to enable secure conversation using the WSE Security Settings Tool.

You'll be working in the Exercises\D\before directory.

        Tasks              Detailed steps

1. Return to Visual Studio .NET 2003. 
   
2. Click File | Open | Project.
   
3. Navigate to C:\Microsoft Hands-on-Lab\DEV-HOL34\VB\Exercises\D\before.
   
4. Open the SecConInvoice.sln in the before directory. This solution consists of two projects: SecConInvoiceClient and SecConInvoiceService. They are identical to the solutions from the previous exercise. All of the security features have been enabled through policy.
   
5. Right click on SecConInvoiceService in Solution Explorer and select WSE 2.0 Settings.
   
6. Go to the Policy tab in the WSE Settings Tool. 
   
7. You need to regenerate the policy statement for each endpoint listed in the Edit Application Policy section. Select the first endpoint listed in the box and click Replace. It will warn you that it's going to overwrite the existing policy. Accept this warning and continue. This will launch the WSE Security Setting Tool again.
   
8. Press Next and specify Secure a service application.
   
9. In the Secure Conversation section, check Use Secure Conversation.
   
10. Press Next and select Username for the client token type.
    
11. Press Next and enter the appropriate role for this endpoint (see Exercise 3 for more details).
    
12. Press Next and select the WSE2QuickStartServer certificate.
     
13. Press Next and Finish the wizard. 
    
14. Repeat this for each of the endpoints listed in the Edit Application Policy section. 
    
15. Press OK to close the WSE Settings Tool.
    
    Note: the service is now configured to use secure conversation. This will only be beneficial to clients that are also configured to use secure conversation. Next, we need to configure the client application the same way.
    
    

Configuring the Client for Secure Conversation

1. Right click on SecConInvoiceClient in Solution Explorer and select WSE 2.0 Settings.
   
2. Go to the Policy tab in the WSE Settings Tool. 
   
3. You need to regenerate the policy statement for the <DefaultEndpoint> listed in the Edit Application Policy section. Select it and click Replace. It will warn you that it's going to overwrite the existing policy. Accept this warning and continue. This will launch the WSE Security Setting Tool again. 
   
4. Press Next and specify Secure a client application. 
   
5. In the Secure Conversation section, check Use Secure Conversation. 
   
6. Press Next and select Username for the client token type.
   
7. Press Next and press Next again (you don't need to enter a role here). 
   
8. Press Next and select the WSE2QuickStartServer certificate. 
   
9. Press Next and Finish the wizard.
   
10. Press OK to close the WSE Settings Tool.
    
    Note: now the client is also configured to use secure conversation. They can now take advantage of the more efficient mechanisms offered by WS-SecureConversation. 
    
11. Build the solution, run the client, and verify that everything works.
    
12. Close the application. 
    
13. Click File | Close Solution.

Exercise 5 Routing Secure Messages

Scenario

One of the major benefits of WS-Security is the fact that it's not dependent on the communication channel. The security features are designed in a transport neutral way. This makes it possible to route messages through multiple intermediaries, and perhaps over multiple protocols, in a secure way. In this exercise, you're going to use WSE 2.0's routing features to route SOAP messages through an intermediary while using various security features covered in this lab.

You'll be working in the Exercises\E\before directory.

        Tasks              Detailed steps

1. Open Windows Explorer and navigate to C:\Microsoft Hands-on-Lab\DEV-HOL34\VB\Exercises\E\before\Router.
   
2. Open referralCache.config in the Router directory and take a look at the file. This file contains referral instructions that will be used by the WSE 2.0 built-in HTTP router. For example, it specifies that when a request comes in for http://localhost/router/ view.ashx, it should be routed to http://localhost/Router Service/ViewInvoices.asmx.
   
   Note: the Router directory was configured as a virtual directory during the setup for this lab.
   
   
3. Right click on referralCache.config in Windows Explorer and select Properties. 
   
4. Browse to the Security tab and click Add…. 
   
5. Type the name ASPNET and click Check Names.
   
6. Click OK. 
   
7. Allow the ASPNET account Full Control. 
   
8. Click OK. 
   
9. The application needs to be configured to use this referral document. Open web.config in the Router directory and verify that it contains the following httpHandler mapping for the SoapHttpRouter class:
   
   <configuration>
     <system.web> 
       <httpHandlers>
         <add type="Microsoft.Web.Services2.
   Messaging.SoapHttpRouter, Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e
   35"
   path="*.ashx" verb="*" /> 
       </httpHandlers> 
     </system.web>
     ...
   
   Note: this entry maps all requests for *.ashx endpoints to the built-in SoapHttpRouter class that knows how to process referral instructions. 
   
   
10. Next, verify that there is a referral element in the microsoft.web.services2 section, specifying the name of the referral
    file:
    
    <configuration> 
      <configSections>
        <section name="microsoft.web.services2" type="Microsoft.Web.Services2. Configuration.WebServices Configuration, Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e 35" />
      </configSections>  
      <microsoft.web.services2>
        <referral>
         <cache name="referralCache.config" />
        </referral>
        ...  
      </microsoft.web.services2>
      ...
    </configuration>
    
    

Configuring the Client for Routing

1. Open RouterApp.sln in the before directory. This solution contains two projects: RouterClient and RouterService.
   
   Note: these applications have various security features enabled through policy files.
   
   
2. Go to the Web References folder of the RouterClient project in Solution Explorer.
   
3. Right click on the localhost node, select Properties, and change URL Behavior to Dynamic. Repeat this step for each Web reference node (localhost1, localhost2, and localhost3).
   
   Note: changing the URL Behavior property to dynamic causes the proxy class to read the endpoint URL from the application configuration file. You'll notice some new elements in the <appSettings> in app.config.
   
   
4. Right click the RouterService project and select Build.
   
5. Right click on the localhost node in the RouterClient project and select Update Web Reference. Repeat this step for each Web Reference node.
   
6. Open app.config in the RouterClient project and locate the <appSettings> element. Modify each URL mapping so the section looks like this:
   
   <configuration>
     ...
     <appSettings>
       <add key="RouterClient.localhost. ViewInvoices" 
   value="http://localhost/router
   /view.ashx"
   />
       <add key="RouterClient.localhost1.
   SubmitInvoice" value="http://localhost/router
   /submit.ashx" />
       <add key="RouterClient.localhost2.
   ApproveInvoice" value="http://localhost/router/
   approve.ashx" />
       <add key="RouterClient.localhost3.
   PayInvoice" 
   value="http://localhost/router/
   pay.ashx"
   />
     </appSettings> </configuration>
   
   Note: these mappings will cause the client application to send its messages to the router virtual directory, which will then route them based on the referral instructions. 
   
   
7. Save app.config.
   

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.