News

Security pioneer: New-age JAAS holds promise

• By Rich Seeley
• October 26, 2004

Tony Nadalin, distinguished engineer and chief security architect for IBM, started working on Java security models with colleagues from Sun Microsystems in the late 1990s, and says that work is now paying off for Java developers.

Nadalin’s goal is to make life easier for Java coders, starting with the initial Java Authentication and Authorization Service (JAAS, pronounced jazz) through work now moving through the Java Community Process (JCP) on standards for encryption and other security issues.

JAAS, which handles the authentication of users who execute Java code and authorization to determine who has access rights to an application, offers a pluggable model that Nadalin says is the future of security for J2EE.

Nadalin, who is co-author of the Web Services Security (WS-Security) standard, serves as IBM’s primary security liaison with Sun and Microsoft. Even his IBM biography describes him as, secondarily, a “corporate employee;” his primary work lies is cooperating with other vendors and standards bodies, including JCP, W3C and OASIS.

The goal of the engineers and architects working on security standards within JCP is to move from adding security extensions for J2EE to making security pluggable, Nadalin says. This will make it possible for Java programmers to buy from any vendor and, in the case of open source, borrow ready-made security technology to plug into their J2EE applications.

This could be a boom for developers working in heterogeneous environments, which Nadalin and most other industry observers see as more the rule than the exception.

"A lot of shops have heterogeneous environments where they have BEA, a Sun box, an IBM box, a Tomcat box," he explains. "So we noticed that there needed to be a way to do pluggable authorization. By that I mean have a hook or the framework in J2EE to be able to call out to an authorization provider. So a security company could write one authorization and have that plug into anybody that was J2EE-compliant."

As Nadalin envisions it this would fullfil Java’s "write once run anywhere" promise, making Java security products easier for vendors to produce and developers to use. As long as a vendor’s security technology is J2EE compliant it would plug into any application developed on an compliant J2EE server. This would save developers and IT departments from having to spend time searching for separate security products for different Java environments in their heterogeneous shop.

However, this is still a work in progress.

"In the Java environment we need to finish the work that Sun and IBM have started on the pluggable authentication mechanism in the J2EE environment," he says. "What this will do is allow us to plug in all sorts of authentication mechanisms."

Enterprise application deployments with requirements for single-sign-on in heterogeneous environments will be prime candidates for pluggable security, Nadalin says.

"Getting the pluggable authentication framework done is high on my list and high on companies’ lists, at least the J2EE vendors, to get complete so they can enter these markets very easily. It’s also in the best interest of OEM vendors, and the security vendors that create products for authentication in a Web services environment."

While pluggable security and all that JAAS may seem arcane to corporate executives, Nadalin says, they will see obvious benefits in application development that will help business. As key security technology, such as secure socket layers, moves into the J2EE standard itself, much of the work of setting up security will be handled with a minimum of programming, which will maximize developer productivity.

"Part of our effort -- where it’s appropriate -- is to drive these things into the base of Java," he says.

When all that work is done, Nadalin says, security will become a matter of setting up security parameters in the J2EE environment, and then having the middleware do the heavy lifting.