Welcome to our blog about all kind of topics that are related to software development. We blog about:

SOA, BPM, EDA, ECM and all the other buzz words. Beware some post might not be so common as you think. We are not scared to go against main stream thoughts.

Technologies like java, maven, springframework, OSGi and front end technologies and frameworks like jQuery, DWR, Flex.

Finally to make this happen we need tools and of course a Mac (well some of us do). So we blog about that as well.


Feeling secure with Web Services – Introduction

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


4 comments to Feeling secure with Web Services – Introduction

  • Goran


    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 ;),

  • 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.

  • Goran

    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!!!

  • I cannot wait to start reading the real stuff :-)

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>