LOS ANGELES--Sun Microsystems plans to introduce a new Java security model this year intended to make the programming language more flexible--but still secure--for business applications.
As part of the Java Development Kit (JDK) 1.2, Sun will augment its existing "sandbox" security model to allow administrators to fine-tune the ability of Java applets to access resources on PCs.
The new model, which Sun terms an "extended" sandbox model, lets companies define security privileges customized for each user or for groups of users. The new model also does away with the concept of trusted code, said Jeff Hong, a business development manager at Sun.
The extended sandbox is intended to address criticisms from developers and system managers that Java's current security policy is too inflexible.
The new model should also maintain Java's reputation as a more secure component model than Microsoft's ActiveX technologies. Instead of a security-based model, ActiveX relies on a trust model in which signatures allow users to judge whether to download an ActiveX control.
If the control is signed by Microsoft, one may be inclined to believe that it is not designed maliciously to reformat your hard drive, for example. If the control is signed by an unknown entity, or if it is unsigned, one may find it too risky to download.
The original sandbox security model was introduced with JDK 1.0. It essentially insulated downloaded Java applets from system resources, so that rogue applets could not gain access to private data. Only the resident JVM (Java Virtual Machine) could get access to system resources.
JDK 1.1 introduced a "trusted" model, where signed applets, which are branded as safe by IS administrators, can gain access to system resources, along with the JVM.
The new extended sandbox in JDK 1.2 works on a permissions model, where all code, both the JVM and applets, is considered unsafe, unless specifically allowed system resource access, based on a predefined policy. The policy can be customized for each user or for groups of users through a concept called "protection domains."
"There is no such thing as trusted code--all code is untrusted," Hong said.
As part of JDK 1.2, Sun will also introduce a new cryptography model, Hong said. Java Cryptographic Extension (JCE) 1.2, currently in beta testing, adds advanced encryption and data security to the JDK. It also allows developers to plug several different cryptography models into the JDK, such as DES, triple DES, and key agreement technology.
Sun has already released a key piece of JDK 1.2 that will give Java applications a variety of faces, or "looks and feels."
Java Foundation Classes 1.1 consists mainly of graphical user interface components code-named Swing.
Developed by Sun and Netscape Communications, the components include standard interface elements such as view options, tool bars, choosers, buttons, and menus that can be added to Java applications. Once a developer designs the interface, she can assign it a specific "look and feel" catering either to Windows, Macintosh, or Solaris. A brand-new Java "look and feel," nicknamed Metal, also is an option.
The native "look-and-feel" options only can be used with their corresponding platforms. In other words, the Windows interface only works on Windows systems and Mac on Mac. However, the Java Metal presentation will run on any platform, according to a JavaSoft spokesman.
JFC 1.1 is a subset of the upcoming JDK 1.2, which is due to be released in early summer. JDK 1.2 will also include support for two-dimensional graphics, multimedia, and other system services, such as drag-and-drop, Sun has stated.
JDK 1.2 will also include CORBA (Common Object Request Broker Architecture) foundations and the latest release of the Java RMI (Remote Method Invocation) specification, which will figure prominently in Sun's efforts to make its Enterprise JavaBeans component architecture a reality.