RE: XML protocol security

Hi Constantine,

The "SOAP object reference" concept is a declared non-goal of the
current SOAP spec. Therefore capabilities cannot fit naturally in SOAP
design. That's because since a capability is nothing more than a
(marshalled) object reference that has associated a set of access rights
which were marshalled together with the reference (because even after
marshalling you must maintain the rule that you cannot perform an action
to a capability unless you have the proper access right to do it).

Certainly the capability-based security solves real problems. For
example, one of the biggest problems with ACL-based security is that you
may have big "if mountains" that can hide security flaws. And more than
that - per global - capabilities can efficiently reduce the amount of
security checkings.

Now, capabilities have their own problems: 
- the lack of ability to administrate the protected resources in a
simple, generic model (as you already noted), like in the case of ACLs.
The entire "protection" scheme relies entirely on the pieces of code
that assigns/retracts access rights for a given capability. The real
security checks are "code driven" and not "data-driven".
- since the capabilities are frequently exchanged between different
modules you cannot really guarantee the "evolution" of a capability
(i.e. which modules will gain control on a certain capability in time)
especially when each module is viewed as a "black box" that receives and
transmits capabilities in an independent way. These guarantees are even
harder to be established in a distributed model like in the case of
Web-based services, when multiple modules are written by independent
software vendors. (check
http://www4.cs.fau.de/~riechman/papers/abstract-smo-nspw-97.shtml for
example)
- unfortunately capabilities says nothing about paradigms like
call-level access check, impersonation or delegation which are pretty
common notions. 
- I didn't found until now any internet standard concerning
capability-based security. Anyone know some activity in this area?

Personally I view ACLs and Capabilities as being two orthogonal design
patterns so in reality you may end up using both. But, anyway, if object
references can be defined as an extension of the SOAP spec I think one
can define a standard for capability-based security on top of that.


Thanks, Adi


<disclaimer> The opinions above are my personal ones </disclaimer>

-----Original Message-----
From: Constantine Plotnikov [mailto:cap@mail.novosoft.ru]
Sent: Wednesday, May 17, 2000 6:23 AM
To: xml-dist-app@w3.org
Subject: Re: XML protocol security

[...]

Because such layers was not fixed yet. I think that we are 
in unique situation that can allow us to promote other security 
models. I found capabilty based security very interesting
model. It is quite unlike ACL model and I think that it suit
web more becuse it will work better in decentralized web. 
More information is available at:

http://www.skyhunter.com/marcs/capabilityIntro/index.html
http://www.caplet.com/security/taxonomy/index.html

Basically I think that there should be following logical 
layers:
1. (Secure) Transport Layer (examples: TCP+SSL, https, ...)
2. Messaging layer (XML-RPC)
3. Secure Distributed Object Model 

The diffculty with ACL is that they make proofs in layer 3 
quite difficult. Sandbox model is an variant of it.

The difficulty with capability based secutrity is that this 
model do not have ready to use simple paradigms of 
administration. At least I have not found it. I have some
ideas but have not yet tested them. Capability based security
is very natural model for mediating services.

Constantine