[
Lists Home |
Date Index |
Thread Index
]
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 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.
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
|
