|
Oracle's Web Services Manager can centrally manage the security policy -- including digital signature generation
July 22, 2008
URL:http://www.drdobbs.com/security/digitally-signing-and-verifying-messages/209400693
Sitaraman Lakshminarayanan is an Enterprise Architect with over 11 years of IT experience in implementing software solutions based on Microsoft and Java platforms. He is the author of Oracle Web Services Manager: Securing Your Web Services, on which this article is based.
Confidentiality and integrity are two critical components of web services. While confidentiality can be ensured by means of encryption, the encrypted data can still be overwritten and the integrity of the message can be compromised. It is equally important to protect the integrity of the message, and digital signatures can help protect the integrity of the message. In this article, I describe how to digitally sign and verify messages in web services using Oracle Web Services Manager, which is a component of Oracle's SOA Suite -- a web services security and monitoring product that helps organizations not only to define and enforce security policies, but also to define and enforce the service level agreements. And one of the key components of Service Oriented Architecture is security.
In the web services scenario, XML messages are exchanged between the client application and the web services. Certain messages contain critical business information and, therefore, the integrity of the message should be ensured. Ensuring the integrity of the message is not a new concept, it has been there for a long time. The concept is to make sure that the data was not tampered with in transit between he sender and the receiver.
Consider, for example, that Alice and Bob are exchanging emails that are critical to business. Alice wants to make sure that Bob receives the correct email that she sent and no one else tampered with or modifi ed the email in between. In order to ensure the integrity of the message, Alice digitally signs the message using her private key, and when Bob receives the message, he will check to make sure that the signature is still valid before he can trust or read the email.
What is this digital signature? And how does it prove that no one else tampered with the data? When a message is digitally signed, it basically follows these steps:
Note: MD5 and SHA1 are message digest algorithms to calculate the digest value. The digest or hash value is nothing but a non-reversible unique string for any given data, i.e. the digest value will change even if a space is added or removed. SHA1 produces a 160-bit digest value, while MD5 produces a 128-bit value.
When Bob receives the message, his first task is to validate the signature. Validation of signature goes through a sequence of steps:
Note: Digital certificates are issued by a trusted party such as Verisign. When a certificate is compromised, you can cancel the certificate, which will invalidate the public key. Once the signature is verifi ed, Bob can trust that the message was not tampered with by anyone else. He can also validate the certificate to make sure that it is not expired or revoked, and also to ensure that no one actually tampered with the private key of Alice.
In the last section, we learned about digital signatures. Since web services are all about interoperability, digital-signature-related information is represented in an industry standard format called XML Signature (standardized by W3C). The following are the key data elements that are represented in an interoperable manner by XML Signature:
In the next section, I describe how the Oracle Web Services Manager can help generate and verify signatures in web services.
Oracle Web Services Manager can centrally manage the security policy, including digital signature generation. One of the greatest advantages in using Oracle WSM to digitally sign messages is that the policy information and the digital certificate information are centrally stored and managed.
An organization can have many web services and some of them might exchange certain business critical information and require that the messages be digitally signed. Oracle WSM will play a key role when different web services have different requirements to sign the message or when it is required to take certain actions before or after signing the message. Oracle WSM can be used to configure the signature at each web service level and that reduces the burden of deploying certifi cates across multiple systems. In this section, we will discuss more about how to digitally sign the response message of the web service using Oracle WSM.
As a quick refresher, in Oracle WSM, each web service is registered within a gateway or an agent and a policy is attached to each web service. The policy steps are divided mainly into request pipeline template and response pipeline template, where different policies can be applied for request or response message processing. In this section, I describe how to confi gure the policy for a response pipeline template to digitally sign the response message. Note: It is assumed that the web service is registered within a gateway and a detailed example will be described later in this article.
In the response pipeline, we can add a policy step called Sign Message to digitally sign the message. To digitally sign a message, the key components that are required are:
The following screenshot describes the "Sign Message" policy step with certain values populated.
The values that are populated are:
The above information is a part of a policy that is attached to the time service which will sign the response message. As per the information that is shown in the screenshot, the BODY of the SOAP message response will be digitally signed using the SHA1 as the digest algorithm, and PKCS12 key store. Once the message is signed, the SOAP message will look like:
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope soap:encodingStyle="http://schemas.xmlsoap.org/
soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:
soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:
soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<soap:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open. org/wss/2004/01/oasis-200401-wss-wssecurity-secext-
1.0.xsd" xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
soap:mustUnderstand="1">
<wsse:BinarySecurityToken ValueType="http://docs.
oasis-open.org/wss/2004/01/oasis-200401-wssx509-token-profile-1.0#X509v3"
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-messagesecurity-
1.0#Base64Binary" wsu:Id="_VLL9yEsi09I9f5ihwae2lQ22" xmlns:wsu="http://docs.
oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-
utility-1.0.xsd">SecurityTOkenoKE2ZA==<
/wsse:BinarySecurityToken>
<dsig:Signature xmlns="http://www.w3.org/2000/09/
xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethodAlgorithm="http://www.w3.org/2001/10/
xml-exc-c14n#"/>
<dsig:SignatureMethodAlgorithm="http://www.w3.org/2000/09/
xmldsig#rsa-sha1"/>
<dsig:Reference URI="#ishUwYWW2AAthrxhlpv1CA22">
<dsig:Transforms>
<dsig:TransformAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>ynuqANuYM3qzhdTnGOLT7SMxWHY=</dsig:DigestValue>
</dsig:Reference>
<dsig:Reference URI="#UljvWiL8yjedImz6zy0pHQ22">
<dsig:Transforms>
<dsig:TransformAlgorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</dsig:Transforms>
<dsig:DigestMethodAlgorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>9ZebvrbVYLiPZ
v1BaVLDaLJVhwo=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>QqmUUZDLNeLpAEFXndiBLk=</dsig:SignatureValue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-
secext-1.0.xsd" wsu:Id="_7vjdWs1ABULkiLeE7Y4lAg22"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-
wss-wssecurity-utility-1.0.xsd">
<wsse:Reference URI="#_VLL9yEsi09I9f5ihwae2lQ22"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
<wsu:Timestamp xmlns:wsu="http://docs.oasis-open.
org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-
utility-1.0.xsd" wsu:Id="UljvWiL8yjedImz6zy0pHQ22">
<wsu:Created>2007-11-16T15:13:48Z</wsu:Created>
</wsu:Timestamp>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="ishUwYWW2AAthrxhlpv1CA22" xmlns:wsu="http://
docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurityutility-1.0.xsd">
<n:getTimeResponse xmlns:n="urn:Test:GetTime">
<Result xsi:type="xsd:string">10:13 AM</Result>
</n:getTimeResponse>
</soap:Body>
</soap:Envelope>
The example XML message is nothing but the SOAP response message that is digitally signed by Oracle WSM. The parameters that are selected or that can be selected will affect the message output and hence it is important to understand how Oracle WSM assembles the digitally signed message.
First of all, Oracle WSM was configured to sign the SOAP body message, which in our example is the actual time from the server. In the above example, the SOAP body is referenced by the identifier ishUwYWW2AAthrxhlpv1CA22. Only the SOAP body message should be digitally signed. We understand that in the signature generation process, we should first calculate the digest value of the message and then encrypt the digest value. In the sample XML, there are a few components which are worth explaining.
The Reference element describes what part of the message is hashed and what digest algorithm is used to create the hash value and any transformations applied before the digest was calculated.
Let's consider a portion of our signed response message and in the message below, we will notice that the DigestMethod is SHA1 and, that the DigestValue is also embedded.
<dsig:Reference URI="#ishUwYWW2AAthrxhlpv1CA22"> <dsig:Transforms> <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </dsig:Transforms> <dsig:DigestMethod Algorithm="http://www. w3.org/2000/09/xmldsig#sha1"/> <dsig:DigestValue>ynuqANuYM3qzhdTnGOLT7SMxWHY=</dsig:DigestValue> </dsig:Reference>
In the above example, there is also an element called Transforms which contains a list of transform elements. The Transform element describes what transformation is applied to the XML message before the digest is calculated. In our example, the Exclusive Canonicalization transformation is used. Note: Since the digest values can differ even when a space is added or removed, canonicalization transformation will transform the data to an accepted format before the digest is calculated.
The SignedInfo element describes the actual signature algorithm and a list of references that contain the digest value of the message. In our case, the signature algorithm is rsa-sha1 and it also contains a reference to the SOAP Body element (Id attribute of the SOAP Body element). In our example of signed SOAP response message, there are actually two reference elements: one that refers to the SOAP Body and an other that refers to the Timestamp element. The SignatureMethod element describes the actual signature algorithm used.
The Signature element is the root element that describes the digital signature. It contains the SignedInfo element, SignatureValue and the KeyInfo element. The SignatureValue element contains the actual signature value and the KeyInfo element contains information about the certificate.
In an earlier section, we learned how the sign message policy step can be configured to digitally sign the message and also the internals of how Oracle WSM creates the signed SOAP response message. In this section, I walk through the signature generation and verification process within Oracle WSM by means of an example.
In this example, I have the same time web service which will be registered within Oracle WSM Gateway. Oracle WSM will validate the incoming signed SOAP message and then will respond with a signed SOAP message. In this example I demonstrate how:
To protect a web service within Oracle WSM, the first step is to register the web service within Oracle WSM and then edit the policy associated with it. The following steps describe how to register the service:
Login to Oracle Web Service Manager Console at:
http://owsm.packtpub.com:3115/ccore
Click on Policy Management and then Manage Services; you will see the List of Gateways that are vailable as shown in the following screenshot.
On the right side of the screen, if you click on the Services hyperlink, you see the list of registered services (refer to the following screenshot).
To add a new service, click on Add New Service on the right side panel.
The previous screenshot show the details that can be added while adding the new service. The * after each label makes those fields mandatory. The screen asks for typical information such as:
It also asks for additional information such as Service Groups, groups that are part of Oracle WSM with the right to view and with the right to update.
In our example, we are registering time service that will validate the signature of the web service request and then will sign the response message. The time service is registered with the following information:
Once the information is filled out, click Next on New Service registration. This will take you to the next screen which will display the actual URL of the service (refer to the following screenshot).
The URL in this page comes from the WSDL URL. You just have to make sure that the service is enabled and check if it is SOAP service or not.
You can then click Finish to register the service. Once you click Finish, the Oracle WSM internally generates a new service ID and now the client applications can use that service ID to communicate.
The previous screenshot show that the Oracle WSM registered the time service and created a new service ID.
Click OK to get back to the main screen that lists all the services.
We have only added the new service, but it hasn't been committed yet. You can now click OK to commit the policy.
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. In this section I describe how to configure Oracle WSM policy to validate the signature of the SOAP request message.
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 the VerifyAndSign 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. 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 confi gured. If you click on the Configure button on the verify signature policy step, it will take you to the screen where you can confi gure the verify signature policy information as shown in the following screen capture. In the previous screenshot, I configured Verify Signature policy steps with:
Note: To generate a PKCS12 key store from certificate that is installed already in Microsoft certificate services, you should fi rst export the certifi cate (with or without private key) and then import that certifi cate in FireFox (Advanced option) and then export back to PKCS12. Once the verify signature policy has been confi gured and saved (Commit Policy), the policy would enforce that any request for the time service with the particular service ID be digitally signed.
In the last section, I 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, I 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. 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. 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 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, I show how to test the web service policy that was just deployed and which digitally signs the response message.
You get 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.
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 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:
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:
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:
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:
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:
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.
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.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.