On Sun, 06 May 2001 12:59:36 PDT, Mark Nottingham said:
The idea is that the identity (i.e., "this is a stockquote service")
is implied by the namespace, and therefore is useful for firewall
admins, etc., so they can work at the granularity of a service type.
The location of the service is still carried in the HTTP
request-line. SOAPAction isn't intended to uniquely name services.
OK.. I've read section 6 of http://www.w3.org/TR/SOAP several times,
and I'm frankly dissapointed.
Unless you find a way to codify that the site has to tell the
truth in the SOAPAction, it's a non-starter. Consider that
the user behind a firewall could, in conjunction with a site
that supported it, just tack onto the end of the URL a
&callit=whateverSoap
and the web site could just label it with SOAPAction=whateverSoap
will get through the firewall.
So what is this actually fixing? The guy *inside* the firewall
presumably knows what will be allowed to pass, and can tell the
guy outside what to call it. This sounds like a scene from a
James Bond movie - if he knows that the roadblock up ahead is
looking for a Jaguar with Swiss plates, he hits a button and
he's now driving a Jaguar with French plates.
This leaves us with 2 choices:
1) Require the SOAPAction to match the XML. Since the firewall
has to poke around the XML then, it renders SOAPAction redundant
and useless. It's also a protocol layering violation egregeous
enough to cause retching.
2) Accept that it's yet another broken protocol that confuses
authentication with authorization (in the worst way - it trusts
the value it's given). I *have* to point out that 4 of the 8
authors work for a company which has historically had problems
in understanding that an attacker might <*gasp*> put incorrect
data into a header field....
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech