Signature Verification by Oracle WSM
Oracle Web Services Manager can actually validate the signature in the incoming i.e. request SOAP message. By using Oracle WSM to validate the signature, organizations can actually centralize the policy enforcement and also the public key management. As organizations deploy more web services that are accessed by other divisions and business partners, managing the signature verification process might become tedious, as with each new consumer, the certificate information should be maintained. Oracle WSM can address such issues by centralizing those operations. This section will describe how to configure Oracle WSM policy to validate the signature of the SOAP request message.
In order to view the policy, you can click on Policy Management and then Manage Policies. This will bring you to the screen with the gateway information and a hyperlink for policies (see the following screen capture).
You can then click on Policies to see all the policies and you will see theVerifyAndSign policy too that is created by default.
A default policy is attached to the service. We can now click Edit to edit the policy. When you click Edit, you will see the policy steps as shown in the following screenshot.
In this section, we want to configure the Request pipeline to validate the signature of the incoming SOAP message. In order to validate the signature, click Add Step Below to add the Verify Signature policy step as shown in the following screenshot.
Once you click OK, the verify signature policy step is added, but that policy step should be configured. If you click on the Configure button on the verify signature policy step, it will take you to the screen where you can configure the verify signature policy information as shown in the following screen capture.
In the previous screenshot, I configured Verify Signature policy steps with:
- Location of the key store
- Key store type as PKCS12
- Password of the key store
- Public key alias in the key store
- Set Remove Signatures to true to remove the digital signature after the signature validation
- Enforce Signing is set to true to make sure that the incoming requests are signed
In order to generate a PKCS12 key store from certifcate that is installed already in Microsoft certifcate services, you should frst export the certifcate (with or without private key) and then import that certifcate in FireFox (Advanced option) and then export back to PKCS12.
Once the verify signature policy has been configured and saved (Commit Policy), the policy would enforce that any request for the time service with the particular service ID be digitally signed.
Signature Generation by Oracle WSM
In the last section, we discussed how to digitally sign a web service request by Microsoft .NET application and how to validate the signature by Oracle WSM. In this section, we will discuss how to digitally sign the web service response message. In the earlier section, we discussed how to register the service and how to attach the verify signature policy step to the request pipeline.
In order to digitally sign the response message, the response pipeline of the policy should be modified to include the sign message policy step. The policy with the request pipeline that is already configured to verify signature would look like:
Now we have to add the step in the Response pipeline to actually sign the response message. In order to add the policy step, click on Add Step Below and then select the Sign Message policy step. Once the Sign Message policy step is added, it can then be configured, as shown in the following screenshot, to include the appropriate key store location for the public key to digitally sign the message.
In the previous figure, the location of the key store that has the private key, along with the Keystore password, alias and part of message to be signed are specified.
Once the policy is created, it would look like:
In the previous screenshot, the Response pipeline has two log steps—one to log the message before digitally signing and one to log the message after digitally signing the message. In this sample, we are using the same WSEQuickStartServer certificate to sign the message.
Once the policy is saved, the response message will be digitally signed. The client application (Microsoft .NET) can be configured to validate the signature.
Oracle WSM Test Page as Client Application
Oracle WSM comes with its own test page where you can test the web service and the security policy associated with the web service. In this example, we will show how to test the web service policy that was just deployed and which digitally signs the response message.
You can get to the test page from the Tools menu.
In the WSDL URL text box, enter the WSDL URL and then click on Submit Query. It will come up with a window to enter any credentials (username and password) and specify if that should be sent in the HTTP header or as a part of the SOAP message. It also has an option to save the test as shown in the following screen capture.
You can give a name for the test and any description and then click Invoke. When you click the Invoke button, the web service is invoked and the test is also saved. In our example, once the web service is invoked, the security policy is applied and the response message is digitally signed as shown in the next screenshot.
In the next example, you will see how to create a client application in Microsoft .NET to perform the signature generation and validation.
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. 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).
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 theproxy 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 article 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 ReceiveSecurityFilterand 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(
// return null;
//Encrypt outgoing msg
return new CustomSecurityClientOutputFilter(this);
public override SoapFilter CreateClientInputFilter(
//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. In order to create the policy, you can click on Add New Item and then select the configuration file, then name your policy file as WSE3CustomSignaturePolicy.config as shown in the following screen capture:
Once the policy file is added, replace the value with the following code:
<extension name="CustomSecurityAssertion" type="Sign
The policy information above describes the location of the certificate 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" ?>
<sectionGroup name="applicationSettings" type="System.
Configuration.ApplicationSettingsGroup, System, Version=184.108.40.206,
Culture=neutral, PublicKeyToken=b77a5c561934e089" >
Version=220.127.116.11, Culture=neutral, PublicKeyToken=b77a5c561934e089
ClientSettingsSection, System, Version=18.104.22.168, Culture=neutral,
PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<section name="microsoft.web.services3" type="Microsoft.Web.
Services3, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf38
<policy fileName="....WSE3CustomSignaturePolicy.config" />
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 _error = "";
SignAndVerify.TimeServiceWse _Proxy =
_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.
In this article, we 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.
If you have read this article you may be interested to view :