[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SOAP-RPC and REST and security
> 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. > 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. > 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. > 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. > 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. > 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? > 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. > 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.
|
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
|