Comments on: Give and take http://stage.vambenepe.com/archives/98 IT management in a changing IT world Thu, 20 Nov 2008 08:24:49 +0000 http://wordpress.org/?v=2.6.3 By: vbp http://stage.vambenepe.com/archives/98#comment-47 vbp Fri, 05 Jan 2007 09:56:24 +0000 http://stage.vambenepe.com/archives/98#comment-47 Sorry about the comment filter Pete. I get your point, you meant this structure: [envelope] [header] ... [/header] [body] ... [/body] [/envelope] And yes, this is of course XML so it can be passed around through HTTP GET, PUT, etc. But when you do it this way, you're not encrypting the whole message since the verb is outside the envelope. Depending on the semantics of your application, it could very well be a serious information leak for someone to see that you're doing a bunch of DELETE or PUT operations. Same problem with regards to signature. If you sent me such a message and sign it, I can prove that you sent me the payload but I can't prove whether it was part of a PUT, a GET or a HEAD. If this is meaningful (and it should be, right?) then I need this information to be signed as well. Otherwise it's like having a contract where the dollar value is signed, but the part that says whether it's a gift or a loan is not. Which is why in these message-level security scenarios you need the verb/action information inside the part of the message that you sign. Sorry about the comment filter Pete. I get your point, you meant this structure:
[envelope]
[header]
…
[/header]
[body]
…
[/body]
[/envelope]
And yes, this is of course XML so it can be passed around through HTTP GET, PUT, etc. But when you do it this way, you’re not encrypting the whole message since the verb is outside the envelope. Depending on the semantics of your application, it could very well be a serious information leak for someone to see that you’re doing a bunch of DELETE or PUT operations. Same problem with regards to signature. If you sent me such a message and sign it, I can prove that you sent me the payload but I can’t prove whether it was part of a PUT, a GET or a HEAD. If this is meaningful (and it should be, right?) then I need this information to be signed as well. Otherwise it’s like having a contract where the dollar value is signed, but the part that says whether it’s a gift or a loan is not. Which is why in these message-level security scenarios you need the verb/action information inside the part of the message that you sign.

]]> By: Pete Lacey http://stage.vambenepe.com/archives/98#comment-45 Pete Lacey Fri, 05 Jan 2007 01:12:52 +0000 http://stage.vambenepe.com/archives/98#comment-45 Damn, you're comment filter removed my XML. Just imagine those elipses being surrounded by Header and Body elements and those being surrounded by an Envelope element. Damn, you’re comment filter removed my XML. Just imagine those elipses being surrounded by Header and Body elements and those being surrounded by an Envelope element.

]]> By: Pete Lacey http://stage.vambenepe.com/archives/98#comment-44 Pete Lacey Fri, 05 Jan 2007 01:10:58 +0000 http://stage.vambenepe.com/archives/98#comment-44 "Once I use WS-Security and the SOAP envelope, I can’t use pure HTTP anymore." Not true. The SOAP envelope is just that, an envelope. Not unlike the HTML envelope. It can be used with plain old HTTP just fine. I can GET a representation that looks like this (namespaces elided for brevity): ... ... And PUT and POST that equally well. It's just XML after all. If the elipses in the Header were replaced with WS-Security related elements, that would present no issues either. Again, it's just XML. Where SOAP goes off the rails is in ignoring HTTP and trying to be protocol/transport agnostic, then, when using HTTP, tunneling _everything_ through POST. But the part of the spec that defines an evelope, that's fine. “Once I use WS-Security and the SOAP envelope, I can’t use pure HTTP anymore.”

Not true. The SOAP envelope is just that, an envelope. Not unlike the HTML envelope. It can be used with plain old HTTP just fine. I can GET a representation that looks like this (namespaces elided for brevity):

…

…

And PUT and POST that equally well. It’s just XML after all. If the elipses in the Header were replaced with WS-Security related elements, that would present no issues either. Again, it’s just XML.

Where SOAP goes off the rails is in ignoring HTTP and trying to be protocol/transport agnostic, then, when using HTTP, tunneling _everything_ through POST. But the part of the spec that defines an evelope, that’s fine.

]]>