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

["Dare Obasanjo" <dareo@microsoft.com>]

> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net] 
> Sent: Wednesday, February 20, 2002 9:33 PM
> To: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] SOAP-RPC and REST and security
> 
> 
> Amy Lewis wrote:
> > 
> >...
> > 
> > Umm.  SOAP/XML Protocol does not require that toolkits 
> generate WSDL 
> > from interfaces, or that they generate stubs from WSDL, or in fact 
> > anything about the deployment process.
> 
> WSDL's verbosity strongly discourages human beings from 
> attempting to read it.

I've seen WSDL files and they don't seem any more difficult to read than
XML schemas or stylesheets. Even then presentation tools can be created
to make them more palatable to those who feel that WSDL files 

> >...
> > The existence of helpful IDEs, even if they break certain 
> programming  
> >principles near and dear to you (and to me, btw ... I agree 
> completely  
> >that offering this sort of silliness is a bad way to design 
> services),  
> >has nothing to do with the protocol definition.
> 
> That's not true. The protocol was designed to make it easy to 
> wrap existing COM/DCOM components. Ask Don Box. That usage 
> model was envisioned since the beginning. I've only ever 
> heard two advantages cited for RPC: 1. It is intuitive 
> because it works just like regular programming 2. It is more 
> compatible with legacy systems and existing functions. Until 
> I hear other advantages of RPC I'm going to presume that 
> these are the two main things. I don't believe that either of 
> them is desirable from a security point of view.

The reason I like RPC for web services is because I can seamlessly
integrate them into my applications in my programming language of
choice. On the other, after looking at the chapters on REST in Fieldings
dissertation I am unclear as to how I can achieve this same degree of
integration using REST. 

> > >2. SOAP lies. HTTP is an application protocol, not a transport 
> > >protocol.
> > 
> > No.
> > 
> > SOAP, in RPC mode, uses HTTP POST to submit a complexly 
> structured set 
> > of parameters, which may or may not be easily expressible using the 
> > traditional name-value pairs associated with a POST.  As a POST, it 
> > implies non-idempotent processing.  An action will be taken.
> 
> Of course most example web services are in fact both 
> idempotent and safe. No action is taken. But more important, 
> most example web services tunnel a new addressing scheme 
> through the Web. Behind a single web resource there are 
> millions of "logical" resources. This is a violation of the 
> Web Architecture which degrades the efficacy of Web logging, 
> filtering and caching tools: in fact any Web intermediary.

I agree that using RPC instead of REST makes it more difficult to
perform logging, caching and filtering. That is an unfortunate tradeoff
that one makes when picking RPC over REST. However, I'd love to a REST
implementation of a non-trivial web service or even better a REST web
services platform before I can decide exactly how significant the
tradeoff. 

> >...
> > It may be a nonstandard use of HTTP, but it certainly 
> breaks no rules,  
> >and in fact is moderately RESTful.
> 
> Every SOAP web service I have ever seen breaks some Web Axioms:
> 
> "In HTTP, anything which does not have side-effects must use GET"
> 
> "Any resource of significance should be given a URI."
> 
> In particular, UDDI is one of the "holy three" specifications 
> and it breaks both of them.
> 
> > >It has syntax and semantics, just as XML has syntax and semantics.
> > 
> > What are the semantics of XML?  XML is syntax ....
> 
> http://www.w3.org/TR/xml-infoset/
> 
> >...
> > HTTP is *a* binding for SOAP.  It is the premier binding, the most  
> >visible, because HTTP is widely deployed, and SOAP fits 
> easily into the  
> >HTTP model: POST a request, receive a response.  SOAP 
> doesn't specify  
> >what lies on the processor side of that.
> > 
> > *Marketing* dorks certainly lie like this, hoping to sell 
> product to 
> > other marketing dorks and get around the evil network-admin BOFH 
> > geekatroids who don't let said marketing dorks park their 
> Win95 boxes 
> > on the internet freely.  I doubt, though, that you're going to find 
> > very many deployments that actually sidestep firewall 
> policy in this 
> > fashion, 'cause the developers *do* talk to, and have 
> (some) respect 
> > for the network admins.
> 
> Then why not use a TCP protocol? It would actually *reduce* 
> the compexity of the spec, clear up the SOAPAction question. 
> Clear up the "Web architecture" question. Improve performance.
> 
> Firewalls are the answer. SOAP was born as 
> DCOM-over-the-firewall and if that's changed since then 
> nobody told the people working on the spec because it still 
> looks like that is the primary goal.
> 
> > >SOAP lies both about what it is doing (POST to do 
> getStockQuote) but
> > 
> > A POST containing standard HTTP parameters that returns a 
> stock quote 
> > is different how?
> 
> Such a use would also be a violation of web architecture. I 
> would take the person to task if I met them. Especially if 
> they were a big company telling people that violating web 
> architecture is a good thing.
> 
> Even so, even the most nasty Perl abuses of HTTP are 
> typically more transparent to firewalls than SOAP because 
> they use method names like /get_stock_quote and /buy_stock 
> and /cell_stock whereas all a firewall generally sees for 
> SOAP is /stock_end_point .
> 
> >...
> > *shrug*  With a big honking SoapAction on them, in case 
> anyone bothers  
> >to look.
> 
> SOAPAction is deprecated.
> 

Which is unfortunate. At least the SOAP 1.2 is still a working draft so
perhaps there is still time to change some minds. Maybe...

<snip stuff about Don Box and MSFT> 

> > ... The two are not the same.  If there is a network admin in the 
> > world who allows free deployment of servlets, components, 
> or whatever 
> > into the corporate firewall, he ought to be fired for incompetence 
> > *before* the first SOAP server gets dropped in (on top of the NCSA 
> > finger CGI, perhaps?).
> 
> How can the network admin *even know* that such a server is 
> running. It just looks like a standard HTTP POST, right? If 
> their policy allows POST then it will be very hard for them 
> to disallow SOAP. 

Most firewalls I know filter based on packet information meaning
primarily source IP, destination IP and destination port. Anything
sophisticated enough to filter based on whether it is a HTTP POST or not
is very likely to be able to do more complex filtering as well. 

> > >If I were Fielding and I carefully designed HTTP to be transparent 
> > >and thus more secure, I would be extremely annoyed to see 
> SOAP hop on 
> > >my bandwagon. The only saving grace is that it will fail 
> and be shut 
> > >down at the firewall again within a year.
> > 
> > Sorry, could you explain how SOAP is defeating transparency?  It's 
> > expanding the syntax of POST parameters.  In the HTTP 
> binding, which 
> > is the most visible, but not at all the only binding.
> 
> The very first line of an HTTP message has three things. A 
> method name, which is supposed to vary, but is always the 
> same for SOAP. A URI, which is supposed to vary based on the 
> data you are working with, but is always the same for a 
> particular SOAP component. All of the important goodies are 
> in the body which is the *exact opposite* of the intent of 
> the HTTP specification. Let me say that again. The whole 
> design of HTTP 1.1 was to make the "protocol" bits of the 
> message as transparent as possible to intermediaries 
> (including firewalls) so that they would not have to look at 
> the body. SOAP puts all of the "protocol" (addressing and 
> data manipulation) bits in the body.

Again you have a good point and I'd like to reiterate that instead of
pointing out the shortcomings of SOAP it's more productive to go ahead
and propose a RESTful alternative or even better to create one and see
where that takes you.  


-- 
THINGS TO DO IF I BECOME AN EVIL OVERLORD #119
I will not attempt to kill the hero by placing a venomous creature in
his room.
It will just wind up accidentally killing one of my clumsy henchmen
instead.