I'm not a security expert by any means, but I favor creating REST-style web services.

In creating a new service which needs to have the data it transmits secure. We've entered a debate over which approach is more secure - REST with HTTPS or a SOAP WS with WS-Security.

I am under the impression we could use HTTPS for all the web service calls and this approach would be secure. The way I look at it is, "if HTTPS is good enough for bank and financial web sites, it's good enough for me". Again, I'm not expert in this space, but I'd think that these people have thought considerably hard about this problem and are comfortable with HTTPS.

A coworker disagrees and says SOAP and WS-Security is the only way to go.

The web seems all over the board on this.

Maybe the community here could weigh in on the pros and cons of each? Thanks!

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

12 Answers
12

HTTPS secures the transmission of the message over the network and provides some assurance to the client about the identity of the server. This is what's important to your bank or online stock broker. Their interest in authenticating the client is not in the identity of the computer, but in your identity. So card numbers, user names, passwords etc. are used to authenticate you. Some precautions are then usually taken to ensure that submissions haven't been tampered with, but on the whole whatever happens over in the session is regarded as having been initiated by you.

WS-Security offers confidentiality and integrity protection from the creation of the message to it's consumption. So instead of ensuring that the content of the communications can only be read by the right server it ensures that it can only be read by the right process on the server. Instead of assuming that all the communications in the securely initiated session are from the authenticated user each one has to be signed.

So WS-Security offers more protection than HTTPS would, and SOAP offers a richer API than REST. My opinion is that unless you really need the additional features or protection you should skip the overhead of SOAP and WS-Security. I know it's a bit of a cop-out but the decisions about how much protection is actually justified (not just what would be cool to build) need to be made by those who know the problem intimately.

An extra point - Transmission security requires authentication of transmission initiator. For example, no good having SSH if everyone knows the password. Multi-layer security is vital in distributed applications. Think Identity, Integrity, Accountability
–
Aiden BellMay 12 '09 at 16:50

13

I saw an interesting mix the other day. A large, F500 customer of ours is using a mix of REST and SOAP (REST for read-only data access, SOAP for the rest) and in order to avoid using different security schemes has decided to use WS-Sec for both. They are doing this by putting the WS-Sec header information into the HTTP headers for the REST calls. Their security intermediary knows how to pull them out of either location to do the checks. First time I had seen this approach.
–
sfittsMay 16 '09 at 17:48

REST inherits security measures from the underlying transport while SOAP defines its own via WS-Security.

When we talk about REST, over HTTP - all security measures applied HTTP are inherited and this is known as transport level security.

Transport level security, secures your message only while its on the wire - as soon as it leaves the wire, the message is no more secured.

But, with WS-Security, its message level security - even though the message leaves the transport channel it will be still protected. Also - with message level security you can partly encrypt the message [not the entire message, but only the parts you want] - but with transport level security you can't do it.

WS-Security has measures for authentication, integrity, confidentiality and non-repudiation while SSL doesn't support non repudiation [with 2-legged OAuth it does].

My apologies but I need to correct this. Look at the Wiki for REST: REST was initially described in the context of HTTP, but it is not limited to that protocol. SOAP has nothing to do with WS-Security and both REST/SOAP implementations to some extent rely on the underlying transport in any case. SOAP is XML-based and therein WS-Security was later layered in as an application-data security implementation. Otherwise good information.
–
Darrell TeagueJan 31 '13 at 22:55

6

As I mentioned above REST doesn't depend on a particular transport - although in most of the time it was explained under the context of HTTP. But, REST does not talk about any security.It totally relies on the underlying transport for security - let it be HTTP or anything. In SOAP - it clearly defines a security standard which does not depend on the transport. WS-Security is designed for SOAP. If you want to use transport level security with SOAP there is no issue, you can use it. REST is an architectural pattern, it does not talk about security.
–
Prabath SiriwardenaFeb 5 '13 at 13:06

REST vs SOAP has been a long non-ending debate. There have been lovers of SOAP but lately the REST is surely catching up. It’s worth mentioning that Yahoo uses REST for all their services including Flickr and del.ici.ous. Amazon and Ebay provide both though Amazon’s internal usage is nearly all REST source. Google used to provide only SOAP for all their services, but in 2006 they deprecated in favor of REST source.

REST

RESTs sweet spot is when you are exposing a public API over the internet to handle CRUD operations on data. REST is focused on accessing named resources through a single consistent interface.

Why REST ?

REST permits many different data formats where as SOAP only permits XML. While this may seem like it adds complexity to REST because you need to handle multiple formats, in my experience it has actually been quite beneficial. JSON usually is a better fit for data and parses much faster. REST allows better support for browser clients due to it’s support for JSON.

REST has better performance and scalability. REST reads can be cached, SOAP based reads cannot be cached.

SOAP

SOAP brings it’s own protocol and focuses on exposing pieces of application logic (not data) as services. SOAP exposes operations. SOAP is focused on accessing named operations, each implement some business logic through different interfaces.

Why SOAP?
WS-Security

While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features. Supports identity through intermediaries, not just point to point (SSL). It also provides a standard implementation of data integrity and data privacy. Calling it “Enterprise” isn’t to say it’s more secure, it simply supports some security tools that typical internet services have no need for, in fact they are really only needed in a few “enterprise” scenarios.

Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.

Its a complete copy paste of : spf13.com/post/soap-vs-rest :) . Can you explain this line "REST reads can be cached, SOAP based reads cannot be cached", why soap can't be cached?
–
LokeshNov 17 '13 at 7:23

3

SOAP, when using HTTP as the transfer mechanism, is sent via HTTP POST requests. As HTTP POST is non-idempotent, it is not cached at the HTTP level
–
AnshuNov 25 '13 at 6:42

In point-to-point situations confidentiality and data integrity can also be enforced on Web services through the use of Transport Layer Security (TLS), for example, by sending messages over https.

WS-Security however addresses the wider problem of maintaining integrity and confidentiality of messages until after a message was sent from the originating node, providing so called end to end security.

As you say, REST is good enough for banks so should be good enough for you.

There are two main aspects to security: 1) encryption and 2) identity.

Transmitting in SSL/HTTPS provides encryption over the wire. But you'll also need to make sure that both servers can confirm that they know who they are speaking to. This can be via SSL client certificates, shares secrets, etc.

I'm sure one could make the case that SOAP is "more secure" but probably not in any significant way. The nude motorcyclist analogy is cute but if accurate would imply that the whole internet is insecure.

I don't yet have the rep needed to add a comment or I would have just added this to Bell's answer. I think Bell did a very good job of summing up the top level pros and cons of the two approaches. Just a few other factors that you might want to consider:

1) Do the requests between your clients and your service need to go through intermediaries that require access to the payload? If so then WS-Security might be a better fit.

2) It is actually possible to use SSL to provide the server with assurance as to the clients identity using a feature called mutual authentication. However, this doesn't get much use outside of some very specialized scenarios due to the complexity of configuring it. So Bell is right that WS-Sec is a much better fit here.

3) SSL in general can be a bit of a bear to setup and maintain (even in the simpler configuration) due largely to certificate management issues. Having someone who knows how to do this for your platform will be a big plus.

4) If you might need to do some form of credential mapping or identity federation then WS-Sec might be worth the overhead. Not that you can't do this with REST, you just have less structure to help you.

5) Getting all the WS-Security goop into the right places on the client side of things can be more of a pain than you would think it should.

In the end though it really does depend on a lot of things we're not likely to know. For most situations I would say that either approach will be "secure enough" and so that shouldn't be the main deciding factor.

Today I had to explain to my girlfriend the difference between the expressive power of WS-Security as opposed to HTTPS. She's a computer scientist, so even if she doesn't know all the XML mumbo jumbo she understands (maybe better than me) what encryption or signature means. However I wanted a strong image, which could make her really understand what things are useful for, rather than how they are implemented (that came a bit later, she didn't escape it :-)).

So it goes like this. Suppose you are naked, and you have to drive your motorcycle to a certain destination.
In the (A) case you go through a transparent tunnel: your only hope of not being arrested for obscene behaviour is that nobody is looking. That is not exactly the most secure strategy you can come out with... (notice the sweat drop from the guy forehead :-)). That is equivalent to a POST in clear, and when I say "equivalent" I mean it.
In the (B) case, you are in a better situation. The tunnel is opaque, so as long as you travel into it your public record is safe. However, this is still not the best situation. You still have to leave home and reach the tunnel entrance, and once outside the tunnel probably you'll have to get off and walk somewhere... and that goes for HTTPS. True, your message is safe while it crosses the biggest chasm: but once you delivered it on the other side you don't really know how many stages it will have to go through before reaching the real point where the data will be processed. And of course all those stages could use something different than HTTP: a classical MSMQ which buffers requests which can't be served right away, for example. What happens if somebody lurks your data while they are in that preprocessing limbo? Hm. (read this "hm" as the one uttered by Morpheus at the end of the sentence "do you think it's air you are breathing?").
The complete solution (c) in this metaphor is painfully trivial: get some darn clothes on yourself, and especially the helmet while on the motorcycle!!! So you can safely go around without having to rely on opaqueness of the environments. The metaphor is hopefully clear: the clothes come with you regardless of the mean or the surrounding infrastructure, as the messsage level security does. Furthermore, you can decide to cover one part but reveal another (and you can do that on personal basis: airport security can get your jacket and shoes off, while your doctor may have a higher access level), but remember that short sleeves shirts are bad practice even if you are proud of your biceps :-) (better a polo, or a t-shirt).

I'm happy to say that she got the point! I have to say that the clothes metaphor is very powerful: I was tempted to use it for introducing the concept of policy (disco clubs won't let you in sport shoes; you can't go to withdraw money in a bank in your underwear, while this is perfectly acceptable look while balancing yourself on a surf; and so on) but I thought that for one afternoon it was enough ;-)

Nice and simple analogy you gave to make difference between https and ws-security. But in real internet, actually most of the time we are in driving our motorcycle naked :D and applying WS-secuirty everywhere would be an overkill in terms of performance and cost. So we can improvise this analogy by taking into account those situation where we need to put on clothes and where putting on clothes would be unneccessary.
–
shashankaholicOct 22 '12 at 10:00

I work in this space every day so I want to summarize the good comments on this in an effort to close this out:

SSL (HTTP/s) is only one layer ensuring:

The server being connected to presents a certificate proving its
identity (though this can be spoofed through DNS poisoning).

The communications layer is encrypted (no eavesdropping).

WS-Security and related standards/implementations use PKI that:

Prove the identity of the client.

Prove the message was not modified
in-transit (MITM).

Allows the server to authenticate/authorize the
client.

The last point is important for service requests when the identity of the client (caller) is paramount to knowing IF they should be authorized to receive such data from the service.
Standard SSL is one-way (server) authentication and does nothing to identify the client.

For instance, do you need to protect your web messages or confidentiality is not required and all you need is to authenticate end parties and ensure message integrity? If this is the case - and it often is with web services - HTTPS is probably the wrong hammer.

However - from my experience - do not overlook the complexity of the system you're building. Not only HTTPS is easier to deploy correctly, but an application that relies on the transport layer security is easier to debug (over plain HTTP).

If your RESTFul call sends XML Messages back and forth embedded in the Html Body of the HTTP request, you should be able to have all the benefits of WS-Security such as XML encryption, Cerificates, etc in your XML messages while using whatever security features are available from http such as SSL/TLS encryption.

REST Over HTTPS Should be a secure method as long as API provider implements authorization a server end. In a case of web application as well what we do is accessing a web application via HTTPS and some authentication/authorization, traditionally web applications did not have security issues then Restful API would also counter security issues without problem !