eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Java, once the latest cool thing, has matured into a key enterprise building block. That solid status should only increase, even with Microsoft Corp.s .Net looming in the rearview mirror, thanks to several important security attributes—not least, the greater maturity—of the Java platform and the technologies that surround it.
Thanks in large part to Microsofts relentless hype campaign for .Net, Web services are top of mind for developers. Its no surprise that Topic 1 on the list of JavaOne sessions next week in San Francisco is “Web Services Today and Tomorrow.” This may, however, beg the question, “Today?”
“I dont know of anybody whos actually been deploying Web services at all,” said Java progenitor James Gosling of Sun Microsystems Inc. in an eWeek interview (see Page 46). One reason for circumspection, Gosling said, is the lack of integrated security measures in the current and forthcoming releases of the specification for Simple Object Access Protocol—which is, essentially, the language of “Web services” as that phrase is now widely used.
Goslings reality check echoed that of Forrester Research Inc., of Cambridge, Mass., whose June 2001 white paper on Web services warned, “Your biggest exposure is security. There is no security standard built into a Web service interface yet. That means you must rely on existing firewall, network and application security.”
That strikes a nerve with IT managers who have had too many unpleasant surprises, many of them tagged with Microsoft trademarks.
“The level of [security] consciousness across the consumer and corporate and government space is very much increased over where its been a year or two years ago,” said Symantec Corp. Director of Research Steve Trilling, in Santa Monica, Calif.
That consciousness has forced the delay of Microsofts .Net servers, yet again, to a revised expected release date in the second half of this year, while Java Services Framework implementations—such as Hewlett-Packard Co.s HP Core Services Framework and the freely downloadable HP Internet Server that incorporates it—are nearing the first anniversary of their initial release. Enterprises concerned about time-to-market issues may feel that its time to stop waiting and get on with Java, especially in view of the massive learning curve involved in training even experienced Windows developers to take on new .Net efforts.
Persistent security problems afflicting Microsofts approach to network-based applications, such as buffer-overflow attacks against unmanaged C++ code, continue to arise in the wake of the shipment of the long-awaited Visual Studio .Net.
When Microsoft, of Redmond, Wash., makes the case for its own solution, .Net CLR (Common Language Runtime), it largely validates the tenets of Java development. Moreover, CLR increasingly appears to be optimized for Microsofts Java-like C# language, despite Microsofts claims of multilanguage neutrality surpassing that of Java Virtual Machine—a contention that Suns Gosling warns is a mixed blessing, even to whatever degree it may be true, due to resulting weakening of provable platform security.
Developers who have already learned Java and who have a nonproprietary services management framework already in place for Java applications, may feel that the industrys six years of refining Java security are more than enough to tip the scales against the unproved security of .Net tools and infrastructure—even if Microsofts claims of superior C# and CLR capability do turn out to have merit.
That attitude was prevalent in a re-cent round-table discussion among members of eWeeks Corporate Partner advisory board. “If you have to do Web stuff today, use Java; its there, its mature and it works,” said one board member, who could not be named at this time. Added another, “Im just not sure the underpinnings of .Net, both its security and its corporate motivation, are what I necessarily want to be a part of yet.”
Technology on the Edge
In addition to the mind share that Java holds as the least risky means of writing secure application code, Java may have an edge as a tool for strengthening other components of enterprise security.
Transactions depend on authentication of both parties, but actual authentications are expensive: Many protocols that are loosely labeled as authentication schemes are merely descriptive, as noted by Andrew Nash, RSA Security Inc.s director of technologies and standards, in remarks at last months RSA conference in San Jose, Calif.
“One has to distinguish,” Nash said, “between a protocol that describes the result of an authentication and a mechanism that actually authenticates.”
Actual authentication is the costly part of the process, and system builders will therefore seek to minimize system costs by authenticating only once in a single-sign-on arrangement; the resulting authentication descriptions must then be passed, securely, from one part of a distributed system to another.
Whenever any of the protocols involved must be implemented anew for a different platform, that creates an opportunity for error that may be exploited by an attacker.
The ubiquity of the Java platform reduces the number of times this risk must arise.
Beyond such theoretical security advantages, JavaOne attendees will hear from line-of-business developers of the DaimlerChrysler AG DealerConnect application environment, a Java 2 Enterprise Edition-based application integration portal planned to serve more than 5,000 dealerships. Crucially, the scheduled discussion of DealerConnect security infrastructure will emphasize approaches that minimize the need for security-related code in individual applications.
Limiting the amount of security code that has to be written could sound like a real advantage to developers whove begun to evaluate the complex security APIs in .Net, as well as represent an improvement over the Java Authentication and Authorization Service package that is part of Java Development Kit Version 1.4.
Physical security is also rising on the radar of enterprise IT following the terrorist attacks of last September, and the role of Java in portable security tokens may also be of growing interest.
Attendees at a previous JavaOne conference were issued rings incorporating Dallas Semiconductor Corp. iButtons: self-contained, Java-based encryption processors, selling today for $32 (in quantities of 1,000), claimed by their maker to be “among the least counterfeitable devices ever made by man.”
Those who can live with something less exotic (and a good deal less costly) can employ the same JavaCard technology used in the iButton with other security tokens, such as smart cards.
Sun, in Palo Alto, Calif., claims complete interoperability of security applications and interfaces among an installed base of more than 100 million JavaCard devices—including 4 million American Express Co. Blue cards and 7 million Visa International smart cards—as of the end of last year.
As in the enterprise security issues discussed above, the length of time that these technologies have been in the field enhances their credibility with security professionals.
Application security and interface security are more than just niche elements of next-generation IT.
Security is the prerequisite to mobility: Without security, most mobile technologies are unacceptably vulnerable to interception and man-in-the-middle attacks.
Security is the foundation of e-commerce: Without it, there can be no spontaneous formation of trust relationships among previously unknown parties, nor can there be guarantees of nonrepudiation of electronic transactions.
Security is the substrate of remotely administered systems and centrally managed code: Without it, all such mechanisms are unacceptable risks.
The ubiquitous interest in security at this years JavaOne therefore represents a readiness to deal with the most serious enterprise concerns. However trendy, and even playful, its early years may have appeared, Java this year is, almost, all business.