RE: [xml-dev] SOAP-RPC and REST and security

["Joshua Allen" <joshuaa@microsoft.com>]

> 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 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
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.