RE: [xml-dev] SOAP-RPC and REST and security

["Joshua Allen" <joshuaa@microsoft.com>]

> protocols. And both make the point about tunnelling, which is a form of 
> fraud. (by the way, I'm in favour of tunnelling in some 
> circumstances...but I know it is an intrinsic blow against security). 

Like when I create a PPTP tunnel over the Internet to dial in to my corporate account?  Is that an intrinsic blow against security?  Like when I use SOAP with XML encryption over HTTP?  That also is a blow against security?  When people start saying things like "tunneling is bad for security, unqualified" or "REST is better than RPC for security, unqualified", my religion-meter starts going berserk.  "There is one REST and no other gods before him" is not a reasonable approach to architecture.

> So to say it "isn't RPC versus REST" is to miss the point. These two 
> people who know ten times more than I do about protocols and security 
> both claim it is *entirely about RPC*. 

I will boil your long argument down to this:  you claim that HTTP in a REST model is secure, because an admin can trust that a GET does not modify resources, and he can control access to other more "dangerous" verbs.  You are upset because embedding SOAP in an HTTP GET (which is by no means a requirement) does not give any such guarantees.

Maybe SOAP is being realistic.  HTTP GET betrayed this promise years ago -- GET *can* modify resources, and any admin who obliviously ignores this fact by adopting your "we can trust REST" attitude is making a serious error.  Saying that "GET does not modify resources, POST might, and PUT will" is nice on paper, but seems to be far past the point of rescue as a practical reality.  If you ask most IT people the difference between GET and POST, they will say "GET allows me to send form parameters on the querystring, so I can use URLs to post form data.  POST allows me to send more information to the form, and is useful when I need to hide the information from prying eyes."  I am not saying this is a desirable understanding, but it sure is how things turned out.  Blame it on the guy who invented FORM METHOD=GET.  Second, people already use form fields (both POST and GET) to directly feed parameters to Java and COM+ objects.  This is not only pervasive, it is considered "best practice" by many shops.

So, is it good advice to tell people that their HTTP+Forms web apps are more secure than SOAP-based apps would be?  I think in fact this is dangerously bad advice.  Best to lose the religion and tell them that security is a discipline, and that they will ultimately need to assign ACLs to the operations that they expose.  At least SOAP doesn't claim to omnipotently solve this problem.