[
Lists Home |
Date Index |
Thread Index
]
- To: "Paul Prescod" <paul@prescod.net>,<xml-dev@lists.xml.org>
- Subject: RE: [xml-dev] SOAP-RPC and REST and security
- From: "Joshua Allen" <joshuaa@microsoft.com>
- Date: Wed, 20 Feb 2002 08:31:24 -0800
- Thread-index: AcG6H0J9ncGW47yHQWmBxPDdVyVv6gACn2og
- Thread-topic: [xml-dev] SOAP-RPC and REST and security
> What are the universal units of access control in XML-based RPC in
> general and SOAP in particular?
Objects and Interfaces. COM+ permits ACLs to be applied to business
objects and methods on those objects. I am sure EJB is the same.
> 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
This is through a nice UI that groups all of the business logic
together. This has been around for many years.
> you say that the underlying object you are working with is reprsented
by
> the concatenation of the fourteen and sixteenth parameters so that you
People define business objects based on actual operations that someone
wants to do. Business operations are not resource representations; I
can see how you might have this problem in a REST world, but people
don't design business objects that way.
And even in this theoretical case, for REST you would be talking about a
regex ACL? I really don't think that makes an admin's job easy. The
interesting thing about RPC is that none of this is theoretical. Banks
and others have this stuff running in production, and the industry has
best practices for designing object models to permit security.
Honestly, I thought it was a common-sense fact that business objects are
easier to assign ACLs to. And then the people who disagree with me are
invariably people who would prefer to set the ACLs on the database and
database views (or stored procedures). I have *never* heard anyone tell
me that they would prefer to set ACLs on parameters of URIs. I am not
saying that it is impossible to have security in REST; just saying that
most people don't seem to think it is very productive to assign security
at that layer, few people do, and most would rather focus somewhere
else.
> reading things into my message. It's amazing. Michael was the one who
I see you saying that REST is inherently more secure than RPC, and
further claiming that bruceS agrees with you. I am just pointing out
that you may be completely wrong on both.
> were secure. And I had to roll significant parts of the security
myself.
> How could I do otherwise?
I guess by using a product that supported hooks to global PKI and
Kerberos? By reading the manual on how to configure security?
|