Channels ▼
RSS

Web Development

Digitally Signing and Verifying Messages in Web Services


Microsoft .NET Client Application

The client application is a Windows Forms application written using Microsoft Visual Studio 2005 with Microsoft WSE 3.0. The first step in creating a client application is to create a Windows Forms application called SignatureGenerationValidationSample.

[Click image to view at full size]
Figure 18

The following is a screenshot on how to create the Windows Forms application. Once you click OK, the Windows Forms application is created with a default form. Since we are going to invoke the time web service with input data, we will add a text box to enter any random input data and a button to invoke the web service.

We will also add another text box to show the Error message if any (refer to the following screenshot).

[Click image to view at full size]
Figure 19

Now we should add the Microsoft WSE 3.0 as a reference before we can create the proxy class. You can add the WSE reference by selecting Add Reference from the project and then selecting Microsoft.Web.Services3. Now that WSE3 is added, we can add a web reference to the web service to create the proxy object. It can be added by right-clicking on the Add Web Reference and then entering the WSDL URL and clicking OK to generate the proxy. So far we have:

  • Created the Windows Forms application
  • Added a reference to WSE3.0
  • Created the web service proxy

The next step is to configure and write code to digitally sign the message. Though it is beyond the scope of this book to explain in detail how to configure policy and write custom policy assertions, we will take a high level overview of how Microsoft .NET and WSE 3.0 can be used to sign and verify SOAP messages. With Microsoft .NET 3.0 and WSE 3.0, the web services security can be applied either through:

  • Policy configuration for certain frequently-used security configurations
  • Custom assertion in combination with policy to perform all other security operations

Since our example focuses only on signing the request and validating the response, we will have to write a custom policy assertion so that SOAP messages can be interpreted both during request and response cycles to perform signature generation and validation. The next step is to write the custom assertion that will:

  • Sign the outgoing message
  • Verify the incoming message

At a high level, the custom assertion inherits from SecurityPolicyAssertion class and has methods such as CreateClientOutputFilter and CreateClientInputFilter that can be overridden to perform any operation at the client side. In our sample, we have created two new classes called CustomSecurityClientInputFilter and CustomSecurityClientOutputFilter to perform any data processing on request or response. The CustomSecurityClientOutputFilter is derived from SendSecurityFilter and has a method called SecureMessage which can be overridden to digitally sign the message.

The CustomSecurityClientInputFilter is derived from ReceiveSecurityFilter and has a method called ValidateMessageSecurity which can be overridden to validate the signature of the message.

The custom security assertion code would look like:

public override SoapFilter CreateClientOutputFilter(
FilterCreationContext context)
{
// return null;
//Encrypt outgoing msg
  return new CustomSecurityClientOutputFilter(this);
}
  public override SoapFilter CreateClientInputFilter(FilterCreationContext context)
{
//Decrypt incoming data
  return new CustomSecurityClientInputFilter(this);
}

The CreateClientOutputFilter and CreateClientInputFilter are overwritten to perform the signature generation or validation. The SecureMessage of CustomSecurityClientOutputFilter is invoked during the outbound transaction and the ValidateMessageSecurity of CustomSecurityClientIputFIlter is invoked during the inbound transaction. Once the custom security is written, it should then be added to the policy. To create the policy, you can click on Add New Item and then select the configuration file, then name your policy fi le as WSE3CustomSignaturePolicy.config as shown in the following screen capture:

[Click image to view at full size]
Figure 20

Once the policy file is added, replace the value with the following code:

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
  <extensions>
  <extension name="CustomSecurityAssertion" type="SignatureGenerationValidationSample.CustomSecurityAssertion,
SignatureGenerationValidationSample" />
  </extensions>
  <policy name="ServicePolicy">
  <CustomSecurityAssertion >
  <clientToken>
  <x509
storeLocation="CurrentUser"
storeName="My"
findValue="CN=WSE2QuickStartClient"
findType="FindBySubjectDistinguishedName" />
</clientToken>
<serviceToken>
<x509
storeLocation="LocalMachine"
storeName="My"
findValue="CN=WSE2QuickStartServer"
findType="FindBySubjectDistinguishedName" />
</serviceToken>
</CustomSecurityAssertion >
</policy>
</policies>

The policy information above describes the location of the certifi cate along with a policy name. Once the policy is added, it should be included with the application configuration file so that the policy can be loaded at run time. The app.config can be replaced with the following to include the custom assertion extensions and the policy extensions.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.
Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" >
<section name="WSSecurtiyClient.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
"
requirePermission="false" />
<section name="SignatureGenerationValidationS
ample.Properties.Settings" type="System.Configuration.
ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
<section name="microsoft.web.services3" type="Microsoft.Web.
Services3.Configuration.WebServicesConfiguration, Microsoft.Web.
Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf38
56ad364e35" />
</configSections>
<applicationSettings>
<SignatureGenerationValidationSample.Properties.Settings>
<setting name="SignatureGenerationValidationSample_
SignAndVerify_TimeService"
serializeAs="String">
<value>http://cpd10cisslaksh.coxinc.com:3115/
gateway/services/SID0003021</value>
</setting>
</SignatureGenerationValidationSample.Properties.Settings>
</applicationSettings>
<microsoft.web.services3>
<policy fileName="..\..\WSE3CustomSignaturePolicy.config" />
</microsoft.web.services3>
</configuration>

Now that the policy file is created, application configuration is modified, and custom assertion is written, we can write the code for the button click event to invoke the web service and attach the policy so that the request can be encrypted and response can be decrypted.

The button click code is straightforward. All it does is:

  • Gather input from the text boxes
  • Instantiate the web service proxy with a WSE-enabled extension
  • Attach the service policy to the proxy
  • Invoke the method

The code will look like:

string _Inputdata = txtInput.Text;
string _Newtime="";
string _error = "";
try
{
SignAndVerify.TimeServiceWse _Proxy =
new SignatureGenerationValidationSample.SignAndVerify.
TimeServiceWse();
_Proxy.SetPolicy("ServicePolicy");
_Newtime = _Proxy.getTime(_Inputdata);
}
catch (Exception ex)
{
txtError.Text = "";
_error = ex.Message.ToString();
}
txtNewTime.Text = _Newtime;
txtError.Text = _error;

If the configurations are correct, you will find the new time in the text box when you run the application.

Summary

In this article, I discussed the importance of digital signatures and how Oracle WSM can be leveraged to digitally sign and verify the messages to ensure the integrity of the message. With digital signatures, especially in validating signatures, each application has to maintain the public key information from each business partner and that will eventually become a tedious task by itself. Oracle WSM can help address such issues by centrally managing the keys and the related policy.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 
Dr. Dobb's TV