Lists Home |
Date Index |
- To: "Paul Prescod" <firstname.lastname@example.org>,<email@example.com>
- Subject: RE: [xml-dev] SOAP-RPC and REST and security
- From: "Joshua Allen" <firstname.lastname@example.org>
- Date: Tue, 19 Feb 2002 22:36:02 -0800
- Thread-index: AcG50yVQMmkJ6RHuTo+31WQidIBP9wAANk3w
- Thread-topic: [xml-dev] 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
> parameters and only becomes dangerous if the fifteenth is a
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
> He shrugged. Not really. Now do you think that your average sysadmin
> 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
> 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 sucker 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
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.