 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 76: RMI Security for J2SETM
Reason: This JSR was not approved by the SE/EE Executive Committee in Draft Approval/Reconsideration Ballots. JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: Define a high-level API for network security in JavaTM 2 Standard Edition RMI, covering basic security mechanisms: authentication (including delegation), confidentiality, and integrity. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Rejected
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: Mark Hodapp E-Mail Address: Mark.Hodapp@sun.com Telephone Number: +1 781 442 2035 Fax Number: +1 781 442 1657 Specification Lead: Bob Scheifler E-Mail Address: Bob.Scheifler@sun.com Telephone Number: +1 781 442 0348 Fax Number: +1 781 442 1657 Section 2: Request
2.1 Please describe the proposed Specification:The proposal is to define a high-level API for controlling network security in RMI, covering basic security mechanisms: authentication (including delegation), confidentiality, and integrity. The intent is not to define new security algorithms or protocols, but rather to define an API that allows applications to readily utilize existing algorithms and protocols in the context of RMI, in such a way that different algorithms and protocols (and different implementations of them) can be plugged in underneath without recoding the applications. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java 2 Standard Edition 2.3 What need of the Java community will be addressed by the proposed specification?
- provides an API that supports a variety of network security implementations - provides increased application portability across different network security implementations - provides integration with other Java platform security mechanisms, such as the Java Authentication and Authorization Service (JAAS) - provides support for non-uniform security: security needs and trust relationships that can vary according to the client, server, operation, and data involved - allows a variety of access control (authorization) schemes to be used - provides an extensible framework that allows other network security features to be added later - allows applications to be written in such a way that network security can be configured without recoding the applications 2.4 Why isn't this need met by existing specifications?RMI does not have any explicit security support today. Users must implement their own security using custom socket factories. 2.5 Please give a short description of the underlying technology or technologies:The API should deal with basic network security: - server authentication: proving to the client that the server is executing on behalf of some subject, so that the remote call can be terminated if the subject is not trusted by the client. The flip side of this is anonymity: allowing a server to remain anonymous when it wants to be - client authentication: proving to the server that the client is executing on behalf of some subject, so that the server can perform only those tasks for which the subject is authorized. The flip side of this is anonymity: allowing a client to remain anonymous when it wants to be - delegation: allowing the server to authenticate as the client in its own remote calls, thus allowing the server to act on a client's behalf when dealing with third party remote servers, in cases where the identity of the client (not the server) is what matters to the third party - confidentiality: making sure that the data sent over the network cannot be interpreted by third parties - integrity: making sure that the data sent over the network is not tampered with by third parties The API should be usable with a variety of underlying network security protocols and cryptographic protocols. For example, the API should be usable with providers implemented using SSL/TLS, Kerberos, GSS-API, and IPsec. 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)java.rmi 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No. 2.8 Are there any security issues that cannot be addressed by the current security model?No. 2.9 Are there any internationalization or localization issues?No. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. 2.11 Please describe the anticipated schedule for the development of this specification.
We will include a preliminary implementation of this API in Merlin Beta for prototyping purposes. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.JavaTM RMI Security - Early Look Draft 3 3.2 Explanation of how these items might be used as a starting point for the work.The draft cited is our current proposal for the RMI security API. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
