When transmitting confidential XML information across the Internet (which is what Web services are all about), there are several security concerns that must be addressed. They include authentication, authorization, confidentiality, integrity, and non-repudiation (which were discussed in detail in my first article on Web service security).
The second and third articles in this series discussed how SAML addresses authentication/authorization issues, and how XML encryption ensures confidentiality of XML documents transmitted across the wire.
This week, I take a look at XML digital signatures, which attempt to address the integrity and non-repudiation aspects of the Web services security realm.
This article first discusses the need for digital signatures, followed by an introduction to basic digital signature concepts. You then learn about XML digital signatures, which enable digital signatures in the Web services world. To some extent, this article builds upon my earlier discussions on XML encryption in my third article, so I recommend that you take a look at it first before delving into the present article.
Some basic terminology:
CryptographyProcess of encrypting/decrypting digital documents to ensure confidentiality
XML Encryption Standard methodology and schema for representing encrypting data within XML
Principal/SubjectA user or a client application or a client Web service, requesting access to a specific resource
W3C (World Wide Web Consortium)Major body that dictates Web service standards and specifications
Need for Digital Signatures
When documents are transmitted electronically across the network, cryptography ensures that no unintended recipients can decipher the contents of the document. In other words, using cryptography, the sender of confidential documents ensures that the receiver is authentic. (You saw earlier what cryptography is and how XML encryption technology enables cryptography in the Web services realm.)
Now, how can the receiver ensure that the sender is indeed who he or she claims to be? After all, the receiver's public key is something that is available in the open, and anybody can have access to it! This is what non-repudiation is all about: to ensure that the sender is indeed authentic. At a later date, in case of disputes, the sender should not deny his role in sending the documents to the receiver.
Another issue that is not ensured by encryption is integrity. What if a small portion of the document has been tampered with? How to ensure that nobody has laid his hands on the encrypted message? We need some mechanism to find whether the contents are in their original form as intended by the sender. This is what integrity is all about.
Non-repudiation and integrity assume alarming dimensions in a service-driven world. Suppose that a confidential XML document is populated by services A and B, and is passed on to service E by C and D. To make things worse, let's assume that these services are provided by different systems/vendors across the Net! Now, how can the end consumer service E ensure the authenticity of the sender services A and B? What guarantee does it have that the XML data passed on from A and B has not been modified during the transit or by other malicious services? With hacking becoming a common phenomenon on the Internet, it is quite possible that unauthorized services will come to life all of a sudden from the network and start consuming confidential business data. How can we make sure that the sender services A and B take full responsibility for what is contained in the XML document?
The technology in the security realm that makes integrity and non-repudiation possible is digital signatures.