XML Digital Signatures

The XML DSig specification is used to provide digital signature functionality to XML Documents.  It is is used by numerous other specs such as WS-Security and SAML2.  This blog entry will describe how digital signatures work with an X509 private/public key pair.

The XML DSig Spec

The XML Digital Signature specification can be found here.

What Benefit Does a Digital Signature Provide?

An incoming message that has a digital signature attached has the following benefits over a message that does not have a digital signature:

  • Know that the holder of the private key used in the digital signature generation is the one who sent the message(of course, this assumes that the private key has not been compromised).  This can be used as a form of authentication.
  • Guarantee that the message that has arrived has not been altered in any way (ie, it has not been tampered with).
  • Non-repudiation or the idea that the sender cannot challenge the validity of the message or its origin.

Note, an XML Digital Signature does not address message encryption.  SSL/TLS or XML Encryption is needed to address this aspect of security.

Who are the Actors?

In the most basic scenario, there are two actors that are involved: Message Sender and Message Receiver.

If a Web Service is introduced that uses a synchronous request-respond Message Exchange Pattern, the two actors become: Service Consumer and Service Provider.

image

Message Sender

The Message Sender generates a message with a Digital Signature and sends it to the Message Receiver.

Message Receiver

The Message Receiver receives a message that contains a digital signature and validates the digital signature.  Once the signature is validated, the actor may take appropriate steps to process the message.

Service Consumer

The Service Consumer creates a request message that contains a Digital Signature and receives a response that also has a Digital Signature.  It isn’t strictly required that the response have a Digital Signature.  For that matter, it isn’t strictly required that the request have a Digital Signature.  For our purposes, we’ll assume that both the request and response messages contain a digital signature.

We are ultimately building up to the use of XML Digital Signature in WS-Security; however, the spec can be used on any properly valid XML document.  So, where we use the term message in this tutorial, we are simply referring to any valid XML document.

Service Provider

The Service Provider receives a request message that contains a Digital Signature, validates the signature, performs processing, generates a response message, adds a Digital Signature to the response message, and sends the response message to the Service Consumer.

How it Works

We are assuming that an enveloped digital signature is being used (ie, the <Signature> block is embedded inside the original XML document).

Digital Signature Generation

The following workflow describes how the Message Sender’s runtime generates a digital signature on a message.

image

Digital Signature Validation

The following workflow describes how the Message Receiver’s runtime validates a Digital Signature.

image

Additional Notes

  • The Message Receiver must check its local truststore to ensure that only valid messages from trusted senders are validated.  Otherwise, any Sender that generates a correct signature regardless of what signer certificate was used will be allowed.
  • The public signer certificate should be embedded in the message.  This will allow the Message Receiver to work with messages from multiple senders easily.
  • Put Issuing Certificates in the Truststore instead of individual signer certificates.  An additional Subject DN check or other check will be needed to ensure only desired signer certificates are accepted.
  • Use of a Digital Signature is usually accompanied by a Timestamp.
  • The Message Receiver will generally dictate whether a Digital Signature is required.  But, this is not always the case.
  • The Digital Signature validation configuration of the Message Receiver side will generally be configured to expect certain parameters that will be described in a WS-SecurityPolicy document or other SLA document between the Message Sender and Message Receiver.

More Information

For additional information about Digital Signatures check out Demystifying WS-Security book (amazon link).