RE: [security-services] Article About SOAP Security

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: RE: [security-services] Article About SOAP Security

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

First of all, I hold no brief for or against SOAP in the abstract.

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.

As far as the firewall/tunneling issue, the idea of using new ports shows a complete ignorance of practical realities. He talks about the CIO deciding what port to open on the firewall. What a joke!!!! Do you really think the CIO has any idea what ports are open on the firewall? If he even knows what brand it is, it's only because he read the PO before signing it.

The reality is that firewalls are religion, not science. Some low level security admin (or perhaps even a consultant) is the one who actually decides what ports to open. (His boss may "officially" make the decision, but he probably knows even less about the issues.) Depending on where the admin learned his religion, he will have different predjudices about how to configure the firewall, but you can bet the one thing he does believe is the fewer ports you open the better. And if this guy decides he doesn't want to open your port you are SOL. Even if you can get the CEO to come to his office and tell him the comnpany will go out of business this week if he doesn't open your port, he is likely to dig in his heels and say, well if you want to take the risk of being hacked... And what is the CEO going to say to that? So naturally, you just use 80 or 443 and nobody complains.

IMO, this problem is not caused by SOAP, but by firewalls and how they get administered. But don't get me started on my rant about heuristic security mechanisms. The main point is that this way everybody wins. The admin doesn't have to think.  The developers can run their SOAP app. The firewall vendors, who thought they were stuck with a commodity product, get to write a lot of new code to parse all the stuff coming through port 80 and differentiate themselves. Plus they will probably will take different approaches, which allows them all claim to be the best. This also gives the analysts something to write about. And it will require a lot more horsepower, so the hardware guys win. And the CIO can upgrade to the latest firewall technology and show how on top of security he is. Those are the real forces that drive security technology introduction.

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.

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. Certainly the statement "Most people agree RPC is not the best model for scalable apps." is provably false. (I mean the "most people" part.)

To me, RPC has three elements: 1) request/response, 2) interoperable marshalling and 3) the program syntax sugar coating. Certainly request response is not right for all applications, but I saw a lot of "conversational" programs which were req/resp in disguise. Interoperability is the name of the game and the more automatic it is the better IMO. And #3 seems to be largely a local matter that you can take or 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.

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.

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?

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.

Hal

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Wednesday, March 20, 2002 10:52 AM
> To: 'Hal Lockhart'
> Subject: RE: [security-services] Article About SOAP Security
>
>
> >Here is an interesting article about SOAP security.
> >http://www.prescod.net/rest/security.html
> >I think some of the things in the article are simply wrong, but is
> worth
> >reading.
>
> I'd be interested in your perspective on what's wrong in the article.
> I've been slowly but surely coming to believe SOAP (let alone RPC) is
> pretty flawed in a lot of ways, so I guess I'm sort of a REST
> convert at
> this point.
>
> -- Scott
>