Java HomeNewsJava-Based AppsDeveloper ToolsDeveloper AssistanceEducationCommunityEventsFeedback
Community - Views and Perspectives


On the Agenda: Java Security
With Java applets proliferating across the enterprise, how secure is Java? Should technology managers be concerned that in opening their doors to this popular programming platform and various Java applications, they're leaving their organizations vulnerable? These are some of the questions posed to Simon Phipps, IBM's program manager for Java technology at the company's Hursley Laboratories in the U.K.

Q: What advice would you give to technology managers who are concerned about Java security?

Phipps: I'd tell them first to start deprogramming what they've heard about Java in the press. Last year some graduate students at Princeton University did research on Java and concluded that there were apparent problems. As a result, Java got some bad press. If you read their reports, however, you'll see they're measuring Java against standards that apply only to an academic nirvana and not the real world. In the real world, Java's security is the best there is to date.

Q: So you're saying Java is secure?

Phipps: Anyone who tells you that your system can be entirely secure is a liar. In evaluating Java you have to weigh the business benefits versus the business risks. And you have to focus on three areas.

Q: Which are?

Phipps: Authentication, verification, and local policy. Suppose a lump of binary stuff from the gods has fallen into my lap. I need to know where that code came from before I use it--that's the authentication. Verification tells me that the code won't do anything nasty to my system if I accept it. The third factor allows my organization to set up parameters for use, such as "don't allow storage on local disk" and the like. Java 1.1 has a security management feature that enables you to do that. With Java, security is built in from the ground up. Security is part of Java; with Microsoft, security is a retrofit.

Q: How does this differ from Microsoft's Authenticode?

Phipps: Microsoft's controls are old fashioned. They view our theoretical binary lump as a single entity. You either say yes or no to the entire entity, and once you accept it you can never get rid of it. Java 1.1 allows you to do a much more fine-grained approach to authentication. You can evaluate each different class of file within that lump and accept or reject those files on an incremental basis. Then, with Java you can also verify if that lump is going to work and verify that each class file is safe. With ActiveX, Microsoft doesn't even attempt to do this. With Microsoft's Authenticode you're trusting the relationship--you trust what comes to you and you trust who created it. You need more than that. Java extends that trust with verification and local policy. Java's approach is to make more than the relationship secure. It's to make the user secure in his or her own right.

Q: So with Java you know where the binary lump came from and can verify whether you can run it safely on your own computer?

Phipps: And, with the local policy controls that are built into Java you can set parameters as to how that code can be used. As an example, you may not want it to touch your hard disk. Java puts the controls in your hands and allows you to set them yourself. Java gives you the flexibility and the controls you need to manage your own security.



JavaTM is a trademark of Sun Microsystems, Inc.

Other companies, products, and service names may be trademarks or service marks of others.

Copyright    Trademark

IBM HomeOrderEmployment