Gridshore » web service

Feeling secure with Web Services – Part 3 – Digital Signature

Allard — Sun, 01 Jun 2008 15:10:55 +0000

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 my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

In part 1 , I’ve dealt with Username Token authentication, an easy to use way to provide an authentication mechanism for your web service.

In part 2 , I have described Transport Layer Security (TLS) -formerly known as Secure Socket Layer- and message encryption.

In this part, the last one in this series, I will explain how the the digital signature can provide some form of security in web services.

Lets recap the security requirements I have discussed in my introduction .

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 each other;
Both parties want to be sure that the message sent is received unchanged.

So far, we have dealt with the first four requirements by implementing Encryption or TLS/SSL or by requiring a UsernameToken from the client. But until now, we are still not the guaranteed that the messages are unmodified since we’ve sent them.

Encryption will prevent modification during the transport between the sender and the final recipient, the one with the private key to decrypt the message. However, once decrypted, the message is free to be modified.

Digital invoices are an example of documents that should be digitally signed. In some countries (in The Netherlands in any case) the Belastingdienst (Tax authority) requires that all digital invoices are digitally signed by the company sending the invoice. This way, the Belastingdienst is able to verify who sent the invoice -the one who signed it- and be sure that it hasn’t been tampered with in the meantime. Of course, the company receiving this invoice wouldn’t really mind to have these guarantees too, I suppose.

Now that we have a real valid use case and are really convinces of the need of the digital signature, let’s have a look at how it works.

Actually, it is almost identical to encryption, but then in the opposite way. With encryption, the message is encrypted using the public key. Only the one with access to the private key can decrypt it. When signing, the private key is used to sign the message, and the public key is used to check the signature. Since access to the private key is limited to authorized people/machines, only they can sign the message. Anyone can access the public part of the key -hence “public”-, meaning that anyone can check the signature.

When a message is signed, the actual message itself is not encrypted. That wouldn’t be very meaningful, because that would mean that anyone would have to decrypt the message, even though they might not really care about the signature. Instead, a hash is creating from all the parts that have to be signed. That hash is then encrypted using the private key. The encrypted has is then inserted in (the header of) the message. Typically, one would also include the public key, to allow anyone to check your signature. That’s it.

To check a signature, the hash is recreated the same way as it was done originally and the encrypted hash from the signer is decrypted. If the message has not been tampered with, the newly generated hash and the decrypted original hash are identical. If they are different, you know the message has been tampered with.

The signature on the message will ensure the reader that the message has not been modified since it has signed sent and that the contents were created by, or created with the consent of, the user who signed it. If you want to see it in action, you can download the example code from the Gridshore google code repository. The demo uses all three forms of security described in this series.

This concludes this three-part article about web service security. The type of security you would choose for your web service clearly depends on the needs of your specific service. UsernameToken provides for an easy to use authentication mechanism, while TLS or message encryption prevents a third party from reading the messages. Finally, the digital signature will ensure that a message is not modified after it is signed.

Feeling secure with Web Services – Part 2

Allard — Mon, 26 May 2008 19:23:04 +0000

In my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

In part 1 , I’ve dealt with Username Token authentication.

In this article, I will describe Transport Level Security (TLS), formerly known as Secure Socket Layer and message encryption.

Lets recap the security requirements I have discussed in my introduction.

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 each other;
Both parties want to be sure that the message sent is received unchanged.

Transport Level Security

Using “Transport Level Security” (TLS), formerly known as Secure Socket Layer (SSL), and also referred to as HTTPS, will take care of requirements 1 and 4.

TLS is a technically very complex algorithm, with a lot of varieties. Fortunately, the general concept is not as hard to grasp. It works as follows:

The client will send a “Hello” to the server.
The server will response with a “Hello”, and send a certificate to the client
The client will decide whether it trusts the server’s certificate
The client will use the servers certificate to encrypt its own certificate and send it back to the server
Depending on the exact algorithm chosen, the client and server will exchange some more encryption information to make the communication “water tight”.

If you really want to know the technical details of TLS, have a look at this page: http://an.wikipedia.org/wiki/Secure_Sockets_Layer. For the typical Web Service developer, these details are not really important. However, knowledge of how the first three steps work can help you prevent a lot of problems.

Especially step 3 is of great importance. The client has received a certificate from the server, and has to decide whether it is safe. This decision is based on a few factors.

First of all, the certificate has to have been issued for the domain that has been requested. So if you access a service on http://somecompany.com/service and get a certificate issued for someothercompany.org, the client will reject the certificate. Some clients, such as web browsers allow the users to override this decision and accept the certificate anyway. A web service client doesn’t typically have a user, so there is no room for second chances.

Secondly, the certificates timestamp has to be valid, meaning that it hasn’t reached it’s expiry date yet. Depending of the type of certificate, it is valid from 1 to tens of years.

The third requirement can sometimes give some problems: the client has to trust the certificate. This can best be explained using a real life example. Imagine yourself at the border control on a foreign airport. If you show them a paper with your name and a signature on it, chances are small that they let you through? Why? Because they can’t trust a self-signed certificate, or one that is signed by a relative. However, if that same name is written on a legal passport, given and signed by your country’s authority, border control will trust it, because they trust them. In TLS, it is exactly the same.

If you order a certificate from a certificate authority (CA), nobody will actually know that you have that certificate. And you don’t trust what you don’t know. However, you have paid the CA to sign your certificate. And maybe the CA certificate has been signed with yet another certificate. Now, if you trust the CA, you will automatically trust all certificates that have been signed with that CA. Back to our border control. If you trust the US government to issue correct passports to people, you will automatically trust all passports of US citizens, even if you don’t know that person.

To mark a certificate as trusted, the certificate has to be stored in a so-called “trust store”. Your browser has a truststore that includes the large CA certificates by default. Just look around in the configuration of your browser. You’ll be able to install other certificates if you like. For example, one that you have created and signed yourself.

You can also configure a truststore for your web service client. By default, your JVM will probably include the large CA certificates, such as Verisign and Thawte. If you’re running on an application server, chances are big there is a trust store configured in them, too. Of course, you can override the truststore by defining your own.

Ok, now that we’ve seen a lot of misery on the client side, let’s have a look at what has to happen on the server side. Well, luckily, not all that much. All you have to do is configure your web server to use SSL. Somewhere along the line it will require you configure a certificate to use. And since you probably want to be trusted, make sure to have your certificate signed by a large CA.

The good part is that all communication between client and server is encrypted in such a way, that only these parties are able to read the messages. And, as a bonus, the client is ensured that it is really talking to the server it was expecting to communicate with.

Message encryption

TLS is nice, but if you have a message that will pass a few endpoints, or has to be logged in the mean time, it doesn’t really help you. If you have to keep your data secure after is has arrived at your first endpoint, message encryption could be your solution.

Let’s start off with an example. Let’s image we have a service where consumers can place orders. Just for the sake of the example, the request will first be processed by an endpoint that checks the stocks. If the stocks are sufficient, the payment is processed. If TLS were used between the consumer and the first endpoint, the message would be sent unencrypted. Of course it is possible to encrypt that communication too, but that would probably be a performance hit.

The idea behind encryption is not really complex. The entire message, or part of it is encrypted using the public key part of the certificate. Since the private key is required to decrypt it, only the recipient (or at least only systems with access to the private key) will be able to so. Even if a message is stored for future reference, the contents will be unreadable to any third party.

Typically, only parts of messages are encrypted. You could think of elements containing payment information or other private contents, such as social security numbers. The example project in go ogle code shows an example of a message where an ID is encrypted. Not a really powerful use case, but it shows how the technology works.

As with TLS, message encryption will deal with items 1 and 4. However, it will only do so for the parts of the message that have been encrypted.

Conclusion

Both TLS and message encryption give the communication between consumer and provider some form or privacy and protection against eavesdropping. If configured correctly, they can work transparently to the implementation of both the client and the consumer, but will claim some of your performance.

My next and last article in this series will discuss message signing, which will deal with the security item that hasn’t been covered yet: “Both parties want to be sure that the message is received unchanged”.

Feeling secure with Web Services – Part 1 – The UsernameToken

Allard — Tue, 20 May 2008 19:25:59 +0000

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 services, 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 my introductory post I’ve elaborated on what type of security we’d typically want on Web Services.

This article will go more in-depth in the Username Token authentication.

First, I’ll list the 5 security requirements we usually have to feel really secured. These have been treated in the introductory post in this series.

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.

The username token will take care of items 2 and 3. The username token is typically a security header in the soap message from the client towards the server. This header contains a username and a password, in one form or another.

In the simplest form, a UsernameToken authentication header contains an element with a username and one with a password. This is the “PasswordText” option of the UsernameToken. When you send this message unencrypted, anyone would be able to read your username and password, an log in on your behalf. Encrypting the communication will solve this risk. However, if the message has to pass several endpoints and one of the connections in unencrypted, your password is open again, despite effort to secure it.

To prevent giving away the username and password combination for free, it is possible to use the “PasswordDigest” version of the UsernameToken. This will actually pass a hash of your password, instead of the password itself. This prevents malicious ears from plucking you password off the wire.

However, although the password is encrypted and unknown to any third party, that third party could log log in by copying the entire security header. After all, if one client can get in using that header, any client could. To prevent this, a Nonce and/or a Timestamp are made part of the hash too. The Nonce is a random value, chosen by the client. The Timestamp is the date and time the password was hashed.

So how does this prevent another user from replicating your authentication header? Well, if a Timestamp is used, the server could require that that timestamp may not be older than for example 5 minutes. This still gives the third party a 5 minute window to abuse your password. That’s where the Nonce comes in. The server can (and should) require that the Nonce may be used at most one time. If the same header -and thus the same nonce- is sent again, the UsernameToken is refused based on a duplicate nonce.

In the end, the security header could look like this:

username Zb5nkZdaXM3hH/bVPQRdMdYSbdo= hHDHOSh3akTwwZFs+6o13A== 2008-05-20T19:00:06.937Z

So, does this make us absolutely secured from any attacks? Well, the likelyhood of anyone abusing your security header is very slim, but nowhere near to zero. Hackers keep lists of commonly used passwords and can use these lists to guess your password. They will see which passwords will create the given hash using the Nonce and Timestamp you have provided. It is therefore very important to generate a password instead of choosing one which is easy to remember. Why would you anyway, a client is usually a piece of software that doesn’t really have difficulties remembering any password. It is of course still not water tight, but it is more likely that the service won’t exist anymore by the time the password has been guessed.

Another way to minimize the chance of abuse of your credentials is by encrypting the messages, or parts of it. This shall be treated in my next post in this series.

The configuration of UsernameToken security in your WebService is fairly simple. Both in client and server only little configuration is needed. There are libraries that can assist you in setting up security, such as Apache’s WSS4J and Sun’s XWSS. If you want to see these libraries at work, make sure you download the code samples for this series on the Gridshore code repository: http://code.google.com/p/gridshore/source/checkout [1].

If you want to go into a little (or a lot) more technical depth of the UsernameToken specification, make sure you read the OASIS WSS specification from http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss#technical.

This concludes this post about the UsernameToken. In my next post in this series, I will shed some light on Transport Level Security and Message Encryption.

[1] Make sure you checkout the code in the /trunk/feeling-secure-with-webservices/ folder. If you check out the entire trunk, you’ll have to deal with lots of samples.

Feeling secure with Web Services – Introduction

Allard — Sat, 17 May 2008 13:45:27 +0000

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:

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:

[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

Why are web services so different from an HTML user interface?

Allard — Wed, 13 Feb 2008 18:41:35 +0000

We all know how a typical web application is usually built up. The image at the side rougly displays the different layers that are to be found in an application. Typically, the user interface layer receives HTTP requests, calls one or more methods in the Business logic layer, and responds with an HTTP message containing HTML.

Nowadays, SOA has come along, and suddenly all enterprise architects want XML web services everywhere. For some reason, many think of SOA as a synonym for “everything must be a web service”. What SOA really is, is not the topic of this article. I want to discuss the position these web services get in the overall picture.

The “Business logic” layer could contain business services that are useful to other applications too. In that case, it might be an option to provide these business services to the “outside world” as XML Web Services. So, the user interface is separated from the rest of the application and replaced with a Web Services interface layer. The business logic is now available to all applications that need it. The user interface that had just been removed is now considered another application that uses the business logic layer through a web services layer.

On paper, it might not even look that ugly. There are, however several major downsides to this approach.

First of all, performance is decreased, as XML Web Service calls cost a lot of processing time. Not only marshalling the request and the response take a lot of time, but HTTP communication takes its toll too.

Something developers will notice, especially after the first release, is that this choice of architecture is difficult to maintain. Most changes that have been requested involve the user interface; a little more information here, something else there, etc. However, to get this information to the front-end, changes have to be made in the business logic, domain model and or the Web Service interface.

The third downside is that the “Business Logic” layer and the “User interface” layer are (often) functionally coupled. The main functions exposed in the view have almost a one-to-one mapping to business services. Splitting these two layers into different application would then sound inappropriate.

So why is this apparently homogeneous application split up into different components?

One thing I have heard is that this is the way SOA prescribes it should be done. I’ve read many documents and specifications, but I have never found a single one that says so. It might be obvious that I disagree.

Another excuse is “versioning”. For some reason, people think more of versioning as a problem than as an opportunity. When done right, versioning of a web service should be a big problem. But a more important question is: why should you version a service? Probably because the business rules in the business logic layer have changed. If that is the case, why keep the old version alive? It uses a deprecated business logic layer. Another reason to version is because the request/response model of the web service doesn’t provide all available information. That can be easily solved by adding either a new service, or an optional parameter to the existing request indicating an extended response is wanted. In my article about Web Service versioning in Java, I go more in-depth on ways services can be versioned (limiting to Java).

However, the most common excuse for the separation is reuse. “Maybe, in the future, more application might want to use this functionality too” is a sentence I have heard more than once too often. Will the business logic ever be used by another application? If that is the case, will the request/response model chosen sufficient for that application? Big chance that the answers are respectively “Most probably not” and “Very little chance”.

It is obvious that I am not fond of this solution. Not because I don’t think it really sounds right, but because I have dealt with this structure in my day to day work. Not somehting I would want to wish you.

I prefer to see the analogy between the User Interface (UI) layer and the Web Services (WS) layer. The UI presents an Business Logic interface to human users. HTML is usually the format of choice. A Web Service layer is exactly that, but then presents the same functionality in another format. For example as SOAP/XML messages. Or as JMS messages on a queue. And let’s not forget REST.

When you see the analogy between the UI and the WS interface, an architectural layout as the image on your right is a good option. In this picture, I have drawn a single “WS” box, but there could be more, depending on the types of services you would like to expose. I have, however, never seen more than one WS interface type in an application, and it usually is a SOAP based web service.

The application is still usable by other applications, accessible for other users and a lot easier to develop. There really aren’t any concessions to be made compared to the completely separated variant. Furthermore, the Web Service only has to be added at the point in time another application actualy needs it. This allows the request/response model to be designed in such a way that external application can take full advantage of the business logic.

I am conviced that the last option provides the most possibilities with the least concessions. And isn’t that exactly what we want? Or did I really miss something? In that case, please leave a comment and let me know.