![]() ![]() (read this "hm" as the one uttered by Morpheus at the end of the sentence "do you think it's air you are breathing?"). What happens if somebody lurks your data while they are in that preprocessing limbo? Hm. 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. 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. 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. However, this is still not the best situation. The tunnel is opaque, so as long as you travel into it your public record is safe. In the (B) case, you are in a better situation. That is equivalent to a POST in clear, and when I say "equivalent" I mean it. (notice the sweat drop from the guy forehead :-)). That is not exactly the most secure strategy you can come out with. 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. Suppose you are naked, and you have to drive your motorcycle to a certain destination. 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 :-)). 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. Today I had to explain to my girlfriend the difference between the expressive power of WS-Security as opposed to HTTPS. For most situations I would say that either approach will be "secure enough" and so that shouldn't be the main deciding factor.īrace yourself, here there's another coming :-) In the end though it really does depend on a lot of things we're not likely to know. Not that you can't do this with REST, you just have less structure to help you.ĥ) 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. Having someone who knows how to do this for your platform will be a big plus.Ĥ) If you might need to do some form of credential mapping or identity federation then WS-Sec might be worth the overhead. ![]() So Bell is right that WS-Sec is a much better fit here.ģ) 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. However, this doesn't get much use outside of some very specialized scenarios due to the complexity of configuring it. Just a few other factors that you might want to consider:ġ) 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.Ģ) It is actually possible to use SSL to provide the server with assurance as to the clients identity using a feature called mutual authentication. I think Bell did a very good job of summing up the top level pros and cons of the two approaches. I don't yet have the rep needed to add a comment or I would have just added this to Bell's answer. 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. My opinion is that unless you really need the additional features or protection you should skip the overhead of SOAP and WS-Security. So WS-Security offers more protection than HTTPS would, and SOAP offers a richer API than REST. There's an amusing explanation involving naked motorcyclists here: ![]() Instead of assuming that all the communications in the securely initiated session are from the authenticated user each one has to be signed. 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. WS-Security offers confidentiality and integrity protection from the creation of the message to it's consumption. ![]() 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. So card numbers, user names, passwords etc. Their interest in authenticating the client is not in the identity of the computer, but in your identity. This is what's important to your bank or online stock broker. HTTPS secures the transmission of the message over the network and provides some assurance to the client about the identity of the server. ![]()
0 Comments
Leave a Reply. |