Friends of Eclipse,
Eclipse is an open source community that benefits millions of developers around the world each and every day! During the month of September, we are asking you to give back to our wonderful open source community. All donations will be used to improve Eclipse technology. Your contribution counts!
We thank you for this gesture, and for giving back to our community.
To ensure Eclipse is a secure runtime, enabling users and administrators to confidently work with the Eclipse client in environments where not all users and/or code sources are friendly. Providing integrated security functionality will allow Eclipse applications to protect their data, to authenticate and authorize valid users, and to protect against potentially malicious code packaged and distributed as plug-ins.
This will be done by enabling Java's standard security mechanisms within the Eclipse platform, defining new functionality where there are gaps in the available standard interfaces. Using Java's core standard interfaces will enable wider integration with code available throughout the Java community.
|August 17, 2007 - M1 release is complete. Update and demo here.|
|August 08, 2007 - Official launch of these security pages. Announcement.|
|July 16, 2007 - Initial contribution of JCA/JAAS framework is approved. Announcement here.|
|May 17, 2007 - A security category is launched on the wiki. Announcement here.|
Provide mechanisms for integrating Java security providers into Eclipse: Applications that need to implement security related functionality require cryptographic services upon which to build. Java provides the Java Cryptography Architecture (JCA) as a mechanism for installing implementations of several interfaces used for cryptography, including MessageDigest, Signature, KeyStore, Certstore, and more. In a typical Java application, these implementations reside in the extensions directory of the JRE. In a dynamic Eclipse application, the appropriate packaging mechanism is in Eclipse plug-ins. The goal is to allow JCA to be used in an Eclipse environment while maintaining the programming model of the JCA subsystem. A related goal is to expose the configuration of the JCA system via an Eclipse-based user interface, allowing authorized users to inspect and modify the Security object.
|JCA/JAAS framework for Eclipse|
Natively support the Java KeyStore and CertStore interfaces for user credential management: When dealing with user's credentials - such as passwords, keys, and certificates - applications need to use some form of secure storage backend for sensitive materials. JCA provides several interfaces that are used for credential management, including KeyStore, CertStore, KeyFactory and CertificateFactory. These interfaces are widely documented, and supported by applications like keytool and KeyStore Explorer. Both KeyStore and CertStore have various uses in the Eclipse environment, including acting as a valuable integration point for 3rd party Java libraries. The goal is to provide native support for these interfaces, such as building UI and tooling that complement them.
|KeyStore support for Eclipse|
Provide an extensible user authentication framework based on Java's JAAS subsystem: In many environments, there are applications which require the user to login before interacting with the system, and provide a different user experience based on the user's login. The Eclipse RCP does not yet support login, and the goal is to provide a framework that will manage the lifecycle of login for an RCP application. Java provides a pluggable system called the Java Authentication and Authorization Service (JAAS), similar to the pluggable authentication module (PAM) systems used in many Linux distributions. JAAS will serve as a basis for this login framework.
|JCA/JAAS framework for Eclipse|
Enable mechanisms for code authorization of signed Java plug-ins: As the Eclipse platform grows as a basis for rich desktop applications, it will become more of a target for authors of malicious viruses. Java provides mechanisms for cryptographically signing Jar files, and ships with a powerful architecture for fine-grained code authorization. Sandboxing is done by enabling a SecurityManager and granting Permissions to application code. Eclipse should provide the ability to enable a SecurityManager and manage Permissions granted to plug-in code via integrated UI. In addition to the fine-grained run-time but resource intensive mechanisms enabled by Java, Eclipse should also explore less granular but potentially more performant and manageable authorization mechanisms - such as checking signatures at bundle install-time, or bundle load-time.
|Signed Java support for Eclipse Platform and IDE|
|Checking bundle signatures at load-time|
|Coding for least-privilege|
Integrate with and support security-aware projects: Several Eclipse projects have already expressed interest in standardized solutions for security fundamentals like the ones listed above. Integrating well with projects like Higgins and the Eclipse Communications Framework is a core goal of the platform security initiative.
A DRAFT plan for the 3.4 release is available here.
We are actively looking for contributors (with or without technology) with interest in this area who are willing to contribute time and resources.
The security initiative will be using the incubator resources with the following details:Wiki: the security wiki category is available here.
Back to the top