Java^TM RMI Security - Early Look Draft 3

Legal Notices

Sun Microsystems, Inc. has patent and other intellectual property rights relating to implementations of the technology described in this Specification ("Sun IPR"). Your limited right to use this Specification does not grant you any right or license to Sun IPR.

THIS SPECIFICATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SUN SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY YOU AS A RESULT OF USING THE SPECIFICATION.

THIS SPECIFICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE SPECIFICATION. SUN MICROSYSTEMS, INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE SPECIFICATIONS AT ANY TIME, IN ITS SOLE DISCRETION. SUN IS UNDER NO OBLIGATION TO PRODUCE FURTHER VERSIONS OF THE SPECIFICATION OR ANY PRODUCT OR TECHNOLOGY BASED UPON THE SPECIFICATION. NOR IS SUN UNDER ANY OBLIGATION TO LICENSE THE SPECIFICATION OR ANY ASSOCIATED TECHNOLOGY, NOW OR IN THE FUTURE, FOR PRODUCTIVE OR OTHER USE.

RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87) and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-1(a).

TRADEMARKS

Sun, Sun Microsystems, the Sun logo, and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

REPORT

As an Evaluation Posting of this Specification, you may wish to report any ambiguities, inconsistencies, or inaccuracies you may find in connection with your evaluation of the Specification ("Feedback"). To the extent that you provide Sun with any Feedback, you hereby: (i) agree that such Feedback is provided on a non-proprietary and non-confidential basis and (ii) grant to Sun a perpetual, non-exclusive, worldwide, fully paid-up, irrevocable license to incorporate, disclose, and use without limitation the Feedback for any purpose relating to the Specification and future versions, implementations, and test suites thereof.

Purpose

This is an early draft of a proposal to add standard security support to Java^TM Remote Method Invocation (RMI). The specification is incomplete, and will change to align with a future version of the Java^TM platform. The document is being published at this time to provide the community with an early look at our design and to solicit feedback on that design, so that we can incorporate any changes as a result of that feedback prior to any official public review. Comments about this draft should be sent to rmi-security-comments@sun.com.

Changes

Significant changes from previous draft:

changed specification style to API documentation generated by the javadoc tool
changed packages from javax.rmi to java.rmi (changed from an extension to an integral part of RMI)
renamed establishProxyTrust method of Security to verifyProxyTrust
replaced ActivatorSecurity interface with ActivatorTrust interface, replaced CheckProxySource interface with ProxyTrust interface, and changed to downloading a verifier object from the server to verify trust in the activator or proxy
added unexportObject method to both SecureUnicastRemoteObject and SecureActivatable
added inactive and unregister methods to SecureActivatable
added register method to SecureActivatable that takes an explicit activation system parameter
removed getSecurityConstraints method from SecureUnicastRemoteObject
added SecureRemoteServer class to hold context methods for secure remote objects, and moved getClientSubject method into SecureRemoteServer from SecureUnicastRemoteObject
changed SecureUnicastRemoteObject and SecureActivatable to be final classes, retaining just the static methods
added SecureHandlerData class and revised the secure InvocationHandler serialization to allow unicast refs to be shared by activatable handlers
added AuthenticationPermission class
added LocateSecureRegistry interface
added RegistryPermission class
added rmisecregistry and rmisecd tools
renamed AuthenticateClient and AuthenticateServer classes to ClientAuthentication and ServerAuthentication, to get uniform noun forms
renamed AlternativeSecurityConstraints class to ConstraintAlternatives
added constructors to ConstraintAlternatives class
added Confidentiality constraint class
changed DelegationDuration and DelegationEndTime classes to contain four values instead of just two, renamed DelegationDuration to DelegationRelativeTime, and renamed DelegationEndTime to DelegationAbsoluteTime
changed ConstraintAlternatives to eliminate constraints implied by other constraints, not constraints that imply other constraints
changed SecurityConstraints class so that all instances are immutable
replaced the intersect and implies methods of SecurityConstraint with a single reduceBy method
changed contextual client constraints to no longer be inherited by child threads and to no longer propagate across exportObject calls
added RMIPermission class
replaced CallAccessControl interface with RemoteCallControl interface
added BasicCallController class
changed MethodConstraints class to allow wildcarded parameter types
changed SecureExportDesc class to check for duplicate MethodConstraints
added SecureExportFile class
revised the security provider interfaces to remove dependencies on TCP/IP
revised the security provider interfaces to allow better preferences discrimination
revised the security provider interfaces to allow better per-call propagation of delegation information
added SecureCallContext class and revised the security provider interfaces to use it
simplified the algorithm for obtaining trust verifiers and endpoint factories from security providers
added getServerSubject method to RemoteSecurity

Introduction

The Java 2 platform provides mechanisms for defining and using fine-grained access control policies, built around the notion of what code is being executed. Permission is granted to code, based on what location the code came from and who signed that code. The Java Authentication and Authorization Service (JAAS) extends the security architecture, providing mechanisms to authenticate subjects (at login), execute code on behalf of subjects, and grant permissions to subjects. The result is that access control policies can be based on both what code is being executed and who is executing that code.

This specification further extends the security architecture to distributed systems built using RMI, by providing mechanisms to mutually authenticate client and server subjects during a remote call, protect the communication from third parties, and execute code in the server on behalf of the client's subject.

The API defined by this specification is intentionally at a very high level; cryptographic mechanisms and protocols are not exposed, so that code written to the API is more portable. An underlying service provider interface allows specific mechanisms and protocols to be configured into the framework.

Although this specification defines additions to RMI, much of the API is designed to be applicable more generally to remote services that are defined in terms of interfaces. A remote service has a front-end proxy object that implements one or more interfaces; the proxy is downloaded into clients that want to use the service. An RMI stub is one form of proxy, but a proxy may also be a more sophisticated object that performs additional computation surrounding an RMI call, or one that uses alternate network protocols.The proxy is responsible for network communication with the back-end remote service, and the implementation of the proxy, including the details of the protocol it uses to communicate with the remote service, can be specialized to the particular implementation of the service. The client does not know about these implementation details; it only knows about the interfaces that define the service.

Reading the Documentation

The following is a suggested order for reading the API documentation and the tool documentation (rmisecregistry and rmisecd). Note that we recommend skipping the detailed semantics of constraint reduction at first, and coming back to it later if you want to understand how to implement a provider.