7 min read

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. So it becomes is equally important to protect the integrity of the message; digital signatures helps us in doing just that.

Overview of Digital Signatures

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 while in transit between the 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 modified 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:

  • Create a digest value of the message(a unique string value for the message using a SHA1 or MD5 algorithm).
  • Encrypt the digest value using the private key—known only to the sender.
  • Exchange the message along with the encrypted digest value.

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:

  • Create a digest value of the message again using the same algorithm.
  • Encrypt the digest value using the public key of Alice(obtained out of band or part of message, etc.)
  • Validate to make sure that the digest value encrypted using the public key matches the one that was sent by Alice.
  • Since the public key is known or exchanged along with the message, Bob can check the validity of the certificate itself.

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 verified, 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.

Digital Signatures in Web Services

In the last section, we learnt 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:

  • What data (what part of SOAP message) is digitally signed?
  • What hash algorithm (MD5 or SHA1) is used to create the digest value?
  • What signature algorithm is used?
  • Information about the certificate or key.

In the next section, we will describe how the Oracle Web Services Manager can help generate and verify signatures in web services.

Signature Generation Using Oracle WSM

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 certificates 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.

Sign Message Policy Step

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 will describe how to configure the policy for a response pipeline template to digitally sign the response message.

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. In order to digitally sign a message, the key components that are required are:

  • Private key store
  • Private key password
  • The part of SOAP message that is being signed
  • The signature algorithm being used

The following screenshot describes the Sign Message policy step with certain values populated.

Oracle Web Services Manager

 

In the previous screenshot, the values that are populated are:

  • Keystore location—The location where the private key file is located.
  • Keystore type—Whether or not it is PKCS12 or JKS.
  • Keystore password—The password to the keystore.
  • Signer’s private-key alias—The alias to gain access to the private key from the keystore.
  • Signer’s private-key password—The password to access the private key.
  • Signed Content—Whether the BODY or envelope of the SOAP message should be signed.

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 us in 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/"    >
  <soap:Header>
    <wsse:Security    
         soap_mustUnderstand="1">
      <wsse:BinarySecurityToken ValueType="http://docs. 
                oasis-open.org/wss/2004/01/oasis-200401-wss- 
                x509-token-profile-1.0#X509v3"  
                EncodingType="http://docs.oasis-open. 
                org/wss/2004/01/oasis-200401-wss-soap-message- 
                security-1.0#Base64Binary" wsu_Id="_ 
                VLL9yEsi09I9f5ihwae2lQ22" >SecurityTOkenoKE2ZA==< 
                /wsse:BinarySecurityToken>
      <dsig:Signature  >
        <dsig:SignedInfo>
          <dsig:CanonicalizationMethod  
                            Algorithm="http://www.w3.org/2001/10/ 
                            xml-exc-c14n#"/>
          <dsig:SignatureMethod  
                            Algorithm="http://www.w3.org/2000/09/ 
                            xmldsig#rsa-sha1"/>
          <dsig:Reference URI="#ishUwYWW2AAthrx 
                             hlpv1CA22">
            <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>ynuqANuYM3qz
dTnGOLT7SMxWHY=</dsig:DigestValue>
          </dsig:Reference>
          <dsig:Reference URI="#UljvWiL8yjedImz
                             6zy0pHQ22">
            <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>9ZebvrbVYLiP
v1BaVLDaLJVhwo=</dsig:DigestValue>
          </dsig:Reference>
        </dsig:SignedInfo>
        <dsig:SignatureValue>QqmUUZDLNeLpAEFXndiBLk
</dsig:SignatureValue>
        <dsig:KeyInfo>
          <wsse:SecurityTokenReference 
 wsu_Id="_7vjdWs1ABULkiLeE7Y4lAg22" 
>
            <wsse:Reference URI="#_
VLL9yEsi09I9f5ihwae2lQ22"/>
          </wsse:SecurityTokenReference>
        </dsig:KeyInfo>
      </dsig:Signature>
      <wsu:Timestamp  
 wsu_Id="UljvWiL8yjedImz6zy0pHQ22">
        <wsu:Created>2007-11-16T15:13:48Z</wsu:
Created>
      </wsu:Timestamp>
    </wsse:Security>
  </soap:Header>
  <soap:Body wsu_Id="ishUwYWW2AAthrxhlpv1CA22" >
    <n:getTimeResponse >
      <Result xsi_type="xsd:string">10:13 AM</Result>
    </n:getTimeResponse>
  </soap:Body>
</soap:Envelope>
Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here