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. 

I think that they will be quite easy to add.

> 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).
> 
AFAIK Rights are not usually marshaled with reference in implementations 
I have seen. Pointer representation was generated with secure random
number generator and some sort of proxy object lived on server. 

Implementation like you described was done in e-speak 2.2 
(www.e-speak.net). But I do not like 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.
> 
The papers that were supplied in the message have good overview of 
the problems related to ACL. 
http://www.skyhunter.com/marcs/capabilityIntro/index.html
http://www.caplet.com/security/taxonomy/index.html

> Now, capabilities have their own problems:=20
> - 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".

This real problem, and the thing (from what I have seen) that is 
most close to it is granting and revoking certificate. But my 
practical knowledge of certificates is more limited. 

Lack of administartion model is caused by fact that you configure 
componenets rather then files and programs and users. I think that 
model can be developed after we will get more expierence. I have 
seen an pontentially interesting model in EJB 1.1 ejb descriptors.
It allow to control what resources are available to ejb-bean. It
also structure points of availability of objects to user.  I think 
that this is a good direction and should be explored more. EJB 
disadvantage is that componenet structure is quite flat but it can
be extended more.

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

But you can know what you give to this program.

If module is the part of system on you server and security in it 
completly capability based, you can control chanels by which it can 
transfer capabilites. If you give pointer to object to other system, 
you can limit harm caused by that system if other system will be 
broken.

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

E system (http://www.erights.org) has quite interesting design for 
distributed model. Have you looked at it?

> (check
> http://www4.cs.fau.de/~riechman/papers/abstract-smo-nspw-97.shtml for
> example)
The paper cannot be downloaded (dead link) so I have not read it.

If the module is part of your application server, capbilites will 
allow you to control chanels available to module. This problem is 
named confinement.
http://www.caplet.com/security/taxonomy/prevention.html
For more information.

> - unfortunately capabilities says nothing about paradigms like
> call-level access check, impersonation or delegation which are pretty
> common notions.=20

These are common notions in today security. But they are caused by
current ACL security achitecture. Capabilities is other way to think 
about security. In short in capability based model you think about
expressibity, it became more simple to understand after I have got 
this idea. 

http://www.skyhunter.com/marcs/capabilityIntro/confudep.html
(it is from http://www.skyhunter.com/marcs/capabilityIntro/index.html)
Practically show exmple of what impersonation can do. 

> - 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.
> 
Maybe "security design" is not very good phrase when comparing
ACL and capabilities. Security Architecture maybe better 
phrase. I do not think that they can be easily mixed, because
they require somewhat different ways thought.

Constantine

Received on Thursday, 18 May 2000 09:20:15 UTC