| Previous | Table of Contents | Next |
When a server passes an object reference, it can be sure that access control policies will apply to any attempt to access
anything through that object reference. When the underlying object is passed as a value, the granularity and level/semantics
of access control are different. In the “by value? case, all the data for the object is passed, and method invocations on
the passed object are local calls that are not mediated by the ORB. Whether the server wants to use the (potentially more
permissive) pass by value access control or not could depend on the security domain, which is receiving the said object or
object reference.
Consider the case where the server S has an object O that it is willing to pass only in the form of an object reference Or'
to a domain Du that it does not trust, but is willing to pass the object by value Ow to another domain Ot that it trusts.
This flexibility is not possible without abstract interfaces. Signatures would have to be written to either always pass references
or always pass values, irrespective of the level of trust of the invocation target domain. However, abstract interfaces provide
the necessary flexibility. The formal parameter type MyType can be declared as an abstract interface and the method invocation
can be coded along the lines of
myExample->foo(security_check(myExample,mydata));
where the security_check function determines the level of trust of myExample's domain and returns an regular interface subtype
of MyType for untrusted domains and a value subtype of MyType for trusted domains. The rules for abstract interfaces will
then pass the correct thing in both these cases.