[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC