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 [1] 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” [2]. 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:

  1. The client must be sure it sends it messages to the correct provider;
  2. The provider wants to be sure that the client is authorized to;
  3. The provider wants to be sure that the client is who it says it is;
  4. Both the consumer and provider want to be sure that the messages can only be interpreted by eachother;
  5. 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:


[1] 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

[2]http://en.wikipedia.org/wiki/Security

Feeling secure with Web Services – Introduction
Tagged on:                 

4 thoughts on “Feeling secure with Web Services – Introduction

  • June 6, 2008 at 8:21 am
    Permalink

    Allard,

    I agree offcourse that a threat analysis is very specific and can differ between implementation depending on requirements. But what I ment was more just to mention it briefly (perhaps in a conclusion) since it is overlooked quite often. People yelling and screaming we need security! We need certificates! While sometimes none of those actually is needed……. :).

    But great articles, have read them al ;),

  • June 1, 2008 at 4:20 pm
    Permalink

    Goran,

    a threat analysis is not something you can do once and then apply on all web services. It’s like having one single figure you can use to say what the chance of theft is in a store. That would of course depend on the location of the store and type of articles sold.

    My goal in these articles is just to provide the information about types of securtiy available and what they actually secure. It’s up to you to do a threat analysis on your own services and decide which type of security you apply.

  • May 26, 2008 at 3:47 pm
    Permalink

    Always an interesting subject, looking forward to your thoughts on digital signing.

    Would be interesting to also see your thoughts on another topic if you could squeeze it in the conclusion:

    – When to implement security. (Threat analysis) 🙂

    Looking forward to your posts!!!

  • May 19, 2008 at 7:38 am
    Permalink

    I cannot wait to start reading the real stuff 🙂

Comments are closed.