Recently, I’ve been helping a customer with some Web Service issues. One of the problems was their limited knowledge of security in that area. He asked me to explain, in Jip and Janneke language  how SSL works and what it actually secures.
There seems to be a lot of misunderstanding about Web Service security. Using password authentication doesn’t prevent unauthorized users to access your data, while SSL / HTTPS doesn’t give you any information about who is trying to access your services. And did you ever think of signing you messages with a digital signature?
In this article, I’ll explain the different methods of securing your Web Services, how each of the methods work and what you actually secure by applying each method.
First, let’s start with a definition of security. Wikipedia describes it as: “Security is the condition of being protected against danger or loss” . This just means that you don’t want anyone stealing your data (expecially during transportation) or doing something unwanted with it. To feel secure in the Web Services area, we want to be assured of the following:
The client must be sure it sends it messages to the correct provider;
The provider wants to be sure that the client is authorized to;
The provider wants to be sure that the client is who it says it is;
Both the consumer and provider want to be sure that the messages can only be interpreted by eachother;
Both parties want to be sure that the message sent is received unchanged.
I will briefly explain each of these items.
Let’s start with the first item. The client is the one initiating the connection. Typically by accessing a URL. For example, http://services.somecompany.com/someService. However, messages towards this endpoint are routed through many routers, switches and proxy servers around the internet. How can you be sure that your messages don’t end up in the servers of “some competiting company”?
On the other side of the connection we want a similar kind of ensurance. How can you be sure that the message comes from a client that has been authorized to access that service? And how do you know the message really comes from that client and not from someone pretending to be an authorized client? Quite often, the use of services is paid for, and you’d want to be sure that nobody is using your services without paying for it.
Regarding the fourth item, just imagine sending a request to a web service provider with an order. That order will probably contain some order items, an address and payment information. If anyone can read that information, it is only a matter of minutes before the credit card number has been abused. We want to be absolutely sure that only the client and the server are aware of the contents of the messages.
And finally, if a message has been tampered with, we want both the client and the server to be able to reject that message. After all, when sending the order again, we wouldn’t want our competitor to intercept the message, change the delivery address to their own (although that would be really easy to trace for law enforcement) and forward the message to the service provider. In some countries, at least in The Netherlands, the tax authority requires that digital invoices are signed by the sender using a trusted digital certificate.
There are several tools, methods and libraries available to achieve one or more of these goals. In my next articles, I will elaborate more on the following topics:
 Jip and Janneke are two very popular cartoon characters for small children. You might just recognize them: http://images.google.nl/images?q=jip+and+janneke&hl=nl&um=1&ie=UTF-8&sa=X&oi=images&ct=title