[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SOAP-RPC and REST and security
Joshua Allen wrote: > > > layers on top like VBScript. But REST certainly encourages security at > > its level much more than RPC does. > > Huh? I know a number of places that have deployed SOAP in production, > using wire encryption, PKI, client certificates, etc. Funny. I didn't mention SOAP. Yes you can (and should!) layer on a bunch of security technologies on top of any protocol. I am talking about the *RPC model* versus the REST model. In particular, the model of business programmers developing new application protocols rather than using well-defined ones. > > is write-only for people outside of our domain." Easy peesy if you use > > HTTP as it was meant to be used. Hard if you use *any* form of RPC > > because the admin doesn't have visibility. A method could take a > hundred > > parameters and only becomes dangerous if the fifteenth is a > priviledged > > userID. > > This is backwards to my experience. Wrapping data access in business > logic gives admins *more* visibility, because they can set ACLs on > particular business operations instead of trying to pick the right mess > of URIs to lock down or open up. REST requires you to wrap data access in business logic. If that was not the case then we'd be sending SQL statements from IE5 to Hotmail. REST is all about separation of implementation from interface. The question is, once you've wrapped up the business logic, how do you expose it as things you can put ACLs on? REST says to use the global namespace that we already have mechanisms for putting ACLs on. This is also in line with the conventions in Unix and Windows of putting files, printers and other resources into a common namespace so that you can apply uniform security policies to them. What are the universal units of access control in XML-based RPC in general and SOAP in particular? > > I talked to an EJB expert about REST. We were talking about security > > models. I described how REST has a natural ACL or capabilities model. > > Hmm, I guess I missed that. But since REST is just a concept that > nobody has ever "implemented properly", I guess it can do anything. Nobody has ever implemented REST perfectly but REST is nevertheless implemented in 100% of the Fortune 500 companies and every one of them I've been to uses some form of access control list. So does the W3C: http://www.w3.org/Member/ > > What's the natural model of RMI (which is basically OO RPC with class > > distribution)? He said that there is some interface you hook in > > arbitrary code and throw an exception if something is wrong. I asked > > "how is that different than just rolling most of the security > yourself." > > He shrugged. Not really. Now do you think that your average sysadmin > is > > going to write Java code to help secure the app? No, they can't. That > > means that all security is in the hands of the developers. They are > > required more or less to invent a new permissions model (probably an > ACL > > workalike) for each app. > > Well, that may be the case for EJB, but I can't comment since I don't do > EJB. However, I suspect that Websphere and BEA have Kerberos hooks, so > I *doubt* the truth of this characterization of EJB. Fine. So you have Kerberos hooks. Now what are the objects that you hook access control to? How are they presented to the security admin? How do you say that the underlying object you are working with is reprsented by the concatenation of the fourteen and sixteenth parameters so that you should be allowed or denied access based on an ACL applied to those two parameters? > > On day I think there will be enough layers between you and REST that > > you'll be a [expletive deleted] without knowing it. But that isn't REST's fault. It > > Of course not; it is always the stupid admins who didn't to this day > ever implement REST properly. I didn't say anything of the sort. You're taking this personally and reading things into my message. It's amazing. Michael was the one who made sweeping statements about REST security. I was the one who said that no, it isn't a panacea. Making one layer secure does not make the entire system secure. Now you're acting as if I claimed that REST is a security panacea. > > Not long ago it was common sense in our industry that you would never > > expose a generic RPC port to the general internet. David Megginson > made > > Whose industry? Maybe you mean the SGML industry? The computer industry. Business programmers should not be forced to implement their own proprietary security model on top of their own proprietary namespace on top of their own proprietary application protocol. That mistake is at the heart of the SOAP+WSDL model. There exist decent application protocols with well-known security characteristics and firewall visibility. We should use them. > > personally would not choose to be on the opposite side of a security > > issue from Bruce Schenier! > > Then maybe you should ask him if he agrees with you. I didn't read > anything in his comments that would indicate that he regards REST as > being inherently secure. REST is not inherently secure. REST encourages security by enforcing a separation of implementation and interface. Furthermore, REST requires the deployment of *no new protocols*. Therefore if Bruce Schenier had anything to say about the security of the three core technologies I'm sure he would have done so by now. URIs are more than 10 years old. HTTP 1.1 and XML are both roughly four years old now. > > You can absolutely define safe systems using RPC. But the tools do not > > encourage it and the very model of RPC does not encourage it. Plus the > > RPC model makes security *verification*, *auditing* and *policy > > creation* much harder. > > Well, this certainly is opposite to my experience, but I will assume for > now that you have some experience implementing enterprise RPC-based > systems to inform your opinions. Are we talking about within enterprises or between enterprises? You can get away with a lot of stuff within an enterprise that you cannot on the public internet. Yes, I've implemented RPC systems in enterprises. They were secure. And I had to roll significant parts of the security myself. How could I do otherwise? Let's say we have a method call like this: class purchase_order_handler: def get_purchase_order(userauth, purchase_order_department, purchase_order_id): .... What in .NET's mechanism that lets an end-user say that if the purchase_order_department is X and th purchase_order_id is Y then the user must be in a certain group? Using URIs I can make purchase_order_department a resource and purchase_order_id a sub-resource. The entire resource is represented as a URI. Default access control would be provided in code. But in any standard web system a standard sysadmin could change the ACLs for a particular purchase order in any of a hundred GUIs that ship with site management systems and portals. I can easily make a web page pointing them to the most important URIs and categorizing the others. Paul Prescod
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|