Recent systems are beginning to offer convenient distributed programming in Java, using a distributed object model similar to that of SRC network objects [5] or CORBA [43]. It would be highly desirable for language based security schemes to easily extend to a distributed environment. A single security policy and implementation mechanism could deal naturally with both local and remote code.
Capabilities extend quite naturally across a network. If remote object references include an unguessable string of bits (i.e., 128 random bits), then a remote capability reference has all the security properties of a local capability [44,15] (assuming all communication is suitably encrypted to prevent eavesdropping). Unfortunately, the confinement issues discussed in section 4.3 become even more problematic. If the capability is leaked to a third party, then the third party has just as much power to use the capability as its intended holder. By themselves, networked capabilities offer no way for an object to identify its remote caller. However, if the remote method invocation used a cryptographically authenticated channel (as provided by SSL [13] or Taos [47]), the channel's remote identity might be useful. Gong [15] and van Doorn, et al. [45] describe implementations of this.
Name space management is comparable to the directory services offered by most RPC systems. The directory server, which can be reached through a well-known mechanism, is used to map names to objects. An interesting possibility would be for a secure directory server to provide different objects to different remote identities.
Stack introspection is interesting because it helps answer the question ``on whose behalf is this request running?''. This can become very complex to answer when RPCs pass through a number of different systems, calling one another. Secure RPC standards [20,35] refer to this as delegation. When Java code is receiving a remote method call and invoking another one, the stack annotations could possibly help mediate the delegation information.
Actually building a secure RPC system using any of the mechanisms in Java is future work. Current Java RPC systems, with the possible exception of Electric Communities [10], have no provisions for flexible security policies.