Thursday, June 30, 2005

SOAP over HTTPS - Part I

5.1 Overview

Soap transactions till now traveled in clear text over the wire which means that anyone with access to the line can gather data about our communication. This is not usually desirable, particularly when we are submitting business information. It is usually convenient in business processes to authenticate the client accessing our server too, and this can be done easily using public key cryptography.

There are a couple of options to secure these transactions. Fist one is to use the security extensions added to Soap protocol, but as yet these are not implemented in Apache Soap. Another option is to use a SSL connection for our Soap transaction with the advantages that SSL is a standard encrypting layer and we only need to modify few things in our source to support it.

If we want to understand SSL connections we need to understand what certificates are and how they work. This has to do with public key cryptography and distribution of public keys. Basically you generate a pair of keys and give your public key to be signed by a trusted authority who ensures that your key really belongs to you. In that way if you trust the certification authority (CA) who signed the key (you should trust well known CAs) you are sure who you are talking to.

To use Soap over a SSL connection you will need a server certificate and possible a client certificate. Both should be signed by a CA.
I will try to explain here how to set up Tomcat and Orion server (under Linux) to use SSL and how to modify your Soap source.

5.2 Certificate configuration

5.2.1 Trust between client and server

Before any information between client and server is transmitted in a SSL communication it is usually required that client and server authenticate each other (although not always required). If this fails the communication is closed.
As client and server can be entities which had never before talked to each other it is necessary a trusted third party which states, in a form of a certificate, that each one is the one who it says to be. This entity is called Certification Authority, from now on CA. There are several well known CAs.
Authentication is achieved by using public key cryptography. Both client and server must have a key pair which is signed by a trusted CA after each party showed proof to its CA of themselves being who they say. CA can be different for client and server as long as the other party trusts the CA who signed the certificate.
If client authentication is required it is necessary that the authorized clients certificates are added to server keystore in advance. This way, at the beginning of a SSL connection and after the initial handshake, certificates are exchanged and checked. After this phase is completed we have a secure encrypted channel which provides us reliable connection by using message integrity check (using hash functions) and in which client and server have authenticated each other.

We will see how to configure server truststore in next part.