RE: [security-services] Article About SOAP Security

[Scott Cantor <cantor.2@osu.edu>]

>I hope you don't mind if I answer on the list, since you and Phill
seemed
>to have started a debate.

I don't want to drag it out into a big thing, because it's mostly about
philosophical questions that are being debated as we speak by a lot of
people, and aren't going to get decided any time soon. It has little to
do with security, really.

>When I used the phrase "simply wrong" what I had in mind in particular,
>was the sentence 'As a trivial example, GET
/getHistoricalStockQuotes?MSFT
>says to a security person: "okay, it's a GET. Barring tunnelling or a
bug,
>it can't modify the server."' Anybody who thinks GET can't be a write
>operation, just does not know anything about real web servers.

That's not entirely true. There are two issues, one pragmatic (clearly
your focus) and one of architecture (Paul's focus and mine to some
extent). As a technical matter, yes, GET can result in side effects. As
a point of web principle, GET should not have "important" side effects
and should be idempotent. It's one of the core axioms. It's why caching
and intermediaries work the way they do.

His caveat is why you're incorrect to say he's wrong. He says "barring
tunneling or a bug...". Sending a message that has a crucial side effect
over a GET is tunneling. If you do that in a closed environment, no
harm, no foul. The REST view of web services is that they be built
without closed-system assumptions whenever possible.

>As far as the firewall/tunneling issue, the idea of using new ports
shows
>a complete ignorance of practical realities.

I understand those realities (and the business and adoption aspects are
really outside of my interest as a non-commercial developer). The point
is, if you use HTTP as it's intended to be used (ie. not by tunneling
over it), then the implications of the traffic can be understood in a
way that a tunneled use cannot. Not fully understood, but more so.

I don't think he makes the point particularly well in that essay,
however.

Th filtering issue is also important, because as it currently stands,
SOAP is text/xml. This is being fixed in the new specs. So if I'm a
firewall admin and I have no policy to guide me from above, I know what
MIME type I'm blocking tomorrow. So much for port 80, and the circle of
life goes on. <cue Wild Kingdom theme>

>I don't understand the relating of URIs or URLs to HTTP. HTTP DOES NOT
USE
>URIs IN ANY WAY. Browsers understand URIs, but HTTP only uses the path
>component.

The web uses them fundamentally. Any hypertext/hypermedia information
system needs universal addressability. You can split the use of a
specific kind of URI and say "HTTP uses the path and TCP uses the
host:port" but web architecture is more than just the transport
semantics of HTTP over TCP. It's also the application semantics of HTTP
and the addressability of resources.

>As far as RPC, I admit that I have not kept up with the latest
arguments,
>but historically, RPCs are to message programming as higher level
>languages are to assembly language. I consider DCOM, CORBA and RMI all
to
>be based on RPC, and that is most of the new distributed applications
>being written.

The frame of reference of that essay (and REST) is the viewpoint that
the web itself is a distributed application which is built on an RPC
interface, namely HTTP. The methods are GET, PUT, POST, and DELETE.
Almost anything I can conceive of can be built on top of that set of
semantics if the advantages to doing so are compelling enough (and the
web fits my definition of compelling).

The REST argument against RPC in the sense of DCE, et al, is to say
"let's compare the success of the web and the number of applications
built with it to every other RPC toolkit, in which the interface and
semantics are defined not globally but anew for every new application".
RPC loses badly.

It's not about whether it's easier for any two developers to write a
complex client and server together, but rather how easy it is for an
application to scale across the planet. Generic behavior, abstraction,
and weak typing make the web work well and avoid the brittle interface
problem.

>Certainly the statement "Most people agree RPC is not the best model
for
>scalable apps." is provably false. (I mean the "most people" part.)

Right. A better statement is that some people think building a new RPC
interface for every new application is not the best way to scale.

>leave if you want. However I should note that DCE and CORBA have shown
how
>security can be seamlessly integrated with RPC, thanks in large part to
>our own TC members Pato and Blakely. So what don't you like? If your
>afraid of buffer overflows, just use Java.

The REST approach in general presumptively dismisses the kind of
app-specific RPC you mean here as having failed at a level far from the
point that security even matters.

When he talks about SOAP, it's a safe bet he's talking about a SOAP
envelope around XML in a general sense, not the data model and the RPC
encoding, which are optional parts of the spec.

>I don't understand the namespace argument. Our product protects all
kinds
>of applications. They use verious syntaxes for resources. In SAML and
>XACML we are assuming we will be able to protect all kinds of
resources.
>Just using the same syntax does buy much.

Security aside, it buys everything on the web. To some, it *is* the web.
SOAP-RPC as currently defined tunnels a completely invisible new arena
of resource manipulation inside the existing space of web resources.
SOAP servers tend to dispatch calls to objects using a single URL,
breaking unique addressability. Fundamentally, it uses POST only, which
makes it entirely impossible to create a link to a SOAP service in a web
resource.

As an example I find funny, UDDI is defined as a SOAP RPC interface, and
as a result, you cannot create a link which is a query to a UDDI
repository. You must intervene with a gateway to do so.

It's quite simply got nothing to do with the web, making the buzzwords
quite ironic and unfortunate.

>Finally he complains about the need for real SOAP security standards.
>Well, that's what we are working on in the TC isn't it?

Sure, though I think we're operating at a different end of the security
spectrum (closer to the application) from the focus of that essay.

>As a courtesy to the others, perhaps we should take the rest of this
off
>the list. But it is only fair for you to respond there next, if you
wish.

Yes, I won't continue to bore people, REST just happens to be something
I've been looking at a lot in the last few months as I've begun to
tackle the kinds of interfaces between systems that I would have used
RPC for in the past.

I got the impression (perhaps mistakenly) that some of the "background
reading" necessary to understand the viewpoint of the essay was worth
pointing out before anybody jumped the poor guy at a conference. ;-)

-- Scott