1.1 Why Java Technology for Enterprise Applications?

Few programming languages and runtimes span heterogeneous multitier distributed computing environments. Prior to the introduction of Java, the client processed Hypertext Markup Language (HTML), Perl, and C/C++, in addition to other programming and scripting languages.

The middle tiers contained the same languages, though often in different combinations, as well as additional languages for performing database queries and messaging. The back-end tier usually contained database query languages, messaging, some amount of scripting, C/C++, and COBOL to access enterprise and legacy resources. Figure 1.1 shows a traditional multitier enterprise environment. Creating an integrated application or suite to address corporate needs across these tiers was a daunting task, especially in a heterogeneous computing environment with multiple languages, development tools, and operating systems.

Figure 1.1. Language Heterogeneity in a Traditional Multitiered Enterprise Environment

1.1.1 Java 2 Platform, Standard Edition

As a programming language and runtime environment, J2SE ”in the clients , middle tiers, and back-end servers ”addresses the challenge of heterogeneous multitiered computing environment by providing a common programming language and runtime environment supported on multiple operating systems. The Java environment acts as a glue to bind these heterogeneous and legacy systems together. Libraries and components exist in J2SE, as well as from other organizations, such as the World Wide Web Consortium (W3C) and Apache, to manipulate the data as it is transformed between the client and back-end servers. These libraries include support for managing and transforming eXtensible Markup Language (XML) documents. However, a single language and its runtime support are insufficient. Additional frameworks are needed to provide structure and design patterns that enable architects , designers, and developers to create and deploy enterprise-scalable applications.

1.1.2 Java 2 Platform, Enterprise Edition

J2EE encompasses a set of enterprise technologies, all integrated through Java Application Programming Interfaces (APIs). These APIs provide the structure needed by enterprise applications. The J2EE technologies include distributed transaction support, asynchronous messaging, and e-mail. In addition, a number of enterprise-critical technologies, including authentication, authorization, message integrity, and confidentiality, are related to security. The J2EE security technologies described in this book afford portable security technologies and APIs that enable interoperable security across the enterprise, even in the presence of heterogenous computing platforms.

1.1.3 Java Components

Before looking at the Java security technologies, it is important to understand the structure of the Java language and runtime environments and how each of the components shown in Figure 1.2 contributes to security.

Figure 1.2. Java Development and Execution Environments and Runtime Libraries, Interfaces, and Architectures

1.1.3.1 Development Environment and Libraries

The Java 2 Software Development Kit (SDK) contains the tools and library code needed to compile and test Java programs. A significant advantage of the Java 2 libraries is that they include integrated support for networking, file input/output (I/O), multithreading, high-level synchronization primitives, graphical user interface (GUI) support, and key security services.

For the most part, the services found in the Java 2 libraries are those found in typical modern operating systems. The difference is that these libraries have been designed to be portable across operating environments. In addition, these libraries contain integrated security features. For example, to open a network connection to another process, the Socket class not only provides the required interfaces but also defines the security authorization requirements for being allowed to open a network connection.

Also, Java code must be written to be type safe. Non-type-safe code will be rejected by the compiler or the runtime. Unlike in C or C++, unsafe type-cast operations are not allowed. For example, in the Java language, it is not possible to cast a String object to be a StringBuffer object in order to modify the value in the String object. In contrast, other languages, such as C and C++, allow sequences of type-safety -violating cast operations.

1.1.3.2 Execution Environment and Runtime Libraries

Execution of a Java program is not a strictly compiled or interpreted program environment. Instead, it is typically a mixed environment that relies on advanced compiler/optimization technologies to enable it to perform well, regardless of the underlying hardware or operating system. The Java Runtime Environment (JRE) processes compiled Java classes at execution time. In particular, the standard Java compiler does not perform many optimizations. Instead, the runtime computes and performs optimizations on the classes during program execution, on the fly. This advanced technology is sometimes referred to as a just-in-time (JIT) compiler.

Like most runtime environments, the JRE includes a set of libraries ”for networking, file I/O, threading, GUI support, and security ”for application developers to use. The J2EE execution environment may include the compiler, debugger, and other tools, although their presence is not guaranteed and depends on the runtime configuration.

It is the responsibility of the runtime to provide the security mechanisms necessary to enforce security at multiple levels. As code is loaded into the runtime, the runtime ensures type safety of the code. For example, even though the compiler made a first-pass attempt at ensuring type safety, it is possible to mismatch classes at runtime. The code may have been compiled with a library version earlier than the one in the execution environment. This mismatch could cause a type-safety failure if not caught. When loading code, the runtime by default performs a type-safety verification, checking for mismatched types. When type-safety violations are identified, the offending code is not loaded into the runtime. In addition, for those cases in which type safety cannot be verified statically, the runtime performs dynamic type safety. Some of the more familiar runtime safety tests include array-bounds checking and type casting.

As code is loaded into the Java runtime, the location from which the code was obtained is recorded, and when the code is digitally signed, the digital signatures are verified. The combination of the location from which the code was loaded and the set of digital signatures used to sign the code is known as a code source and is implemented as a java.security.CodeSource object. The CodeSource s are used to determine whether classes executing in a thread are authorized to access protected resources. In particular, whenever the runtime libraries perform authorization tests, the CodeSource for each class is used in determining whether the class is authorized to access a protected resource.

As of J2SE V1.4, the runtime also contains an integrated framework for authenticating and authorizing principals (users, systems, or other accountable entities). This framework is called JAAS. Principal-based authentication and authorization are familiar to most users of computing systems. JAAS usually manifests itself through a login process and restrictions placed on access to computing resources. The support for JAAS both supplements and complements the previously existing support for CodeSource -based authorization mechanisms. J2EE V1.3 does not require J2SE V1.4 but must support the JAAS API and framework, as explained in Section 9.4 on page 338.

1.1.3.3 Interfaces and Architectures

Java programs interact with the non-Java world through a set of standard interfaces, or APIs. This interaction includes accessing databases, messaging systems, and processes running in other systems. Many of these interfaces interact with architected subsystems that enable multiple vendors to provide the services in a vendor-neutral manner. Thus, the application can access a set of services without writing to proprietary APIs.

Examples of nonsecurity interfaces and architectures include Java Database Connectivity (JDBC), for access to databases; and Java Message Service (JMS), for access to messaging systems. In the security arena, JCA supplies standard interfaces and architectures for creating and accessing message digests and digital signatures, whereas JCE adds support for encryption. JAAS provides a standard architecture and interfaces for defining and using authentication and authorization services.

1.1.4 Java Security Technologies: Integral, Evolving, and Interoperable

Java security has not been an afterthought, as it is in most programming languages and environments. From its early days as a client-side programming technology, Java security features have included type safety and the ability to create a security sandbox that prevents code from unauthorized access to protected computing resources, such as networking and file I/O.

From a security perspective, Java has grown and matured to include an architecture and a set of interfaces to enable a wide range of cryptographic services via JCA and JCE, support for Secure Sockets Layer (SSL) and Transport Layer Security (TLS) via JSSE, Secure/Multipurpose Internet Mail Extensions (S/MIME), and PKI support, including digital certificate path validation via CertPath. One of the main goals for Java has been to support those cryptographic security services, as well as authentication and authorization services through JAAS. In particular, Java supports Kerberos, a network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography; and Generic Security Services (GSS), a protocol for securely exchanging messages between communicating applications. Support for GSS is embedded in the Java GSS API (JGSS-API).

All these services are based on a set of widely recognized and supported standards. Because they are founded on existing standards, Java-based applications can interoperate with existing, or legacy, computing services. The Java development community has expended substantial effort in compliance and interoperability testing. Thus, application and system developers can be assured that Java-based services, including those for security, are interoperable and portable. Figure 1.3 shows the Java security technologies and how they interrelate.

Figure 1.3. Java Security Technologies

The Java technology had security as a primary design goal from the very beginning. Originally, however, Java technology lacked a number of important security features. The technology has since matured to include some essential cryptographic services, as previously mentioned. Also, one of the security services lacking in the earlier Java versions was a standard architecture and interfaces for performing principal-based authentication and authorization. Although it had a well-developed architecture for authenticating the origins of code executing in the Java runtime, the Java technology lacked standard mechanisms for authentication typically found in server environments. JAAS has filled this gaping hole by providing the means for authenticating a principal and performing authorization based on whether the authenticated principal is authorized to access a specific protected resource.

What is unique about Java support for security is its ability to provide essentially the same collection of security services across a set of heterogeneous computing platforms. Because of these cross-platform capabilities, the set of server-side security features is available on all server platforms, making Java application code and security services highly portable, able to work in heterogeneous computing environments, and able to communicate with non-Java applications and services. For example, a Java program can communicate through an SSL connection or use Kerberos and interoperate with other services and processes not written in the Java language. This book describes how Java technology is used to create sophisticated server-side applications that can be protected using the security technologies found in an enterprise application development and deployment environment.

1.1.5 Portability in a Heterogeneous World

Most enterprises comprise heterogeneous computing environments. The client-side operating systems include various versions of Microsoft Windows and several flavors of UNIX or Linux, which may be different from the operating systems running on the enterprise servers. Larger enterprises have a server computing environment that also is heterogeneous. This heterogeneity can pose a significant cost to the organization in terms of development, deployment, and interoperability. Heterogeneity can be an impediment to interoperability and integration of computing resources. When this happens, the organization is unable to integrate the services that make it more efficient and competitive.

One of the really tough challenges for enterprises is the creation of applications that can be written and tested on one platform and run on other platforms. Java technology, including J2EE, strives to enable application developers to write and test applications in development environments that are familiar to the developers but that allow deployment and testing in less familiar environments. For example, the development can be performed on a desktop operating system and the code deployed on a mainframe. Few programming languages and development environments can make such a claim.

In addition, few environments can claim to support a broad and common set of security services on the same range of platforms. This level of portability is a tremendous benefit to many organizations that have applications running across a set of heterogeneous computing environments. The cross-platform development and deployment, along with the broad industry support for security, database, and messaging services, are tremendous benefits to organizations that are under pressure to develop and deploy secure applications in heterogeneous environments.

Much of the portability and interoperability of applications are derived from the broad set of services available via the Java runtime libraries. These libraries eliminate or vastly reduce the need for native, or non-Java, code. In fact, J2EE discourages the use of native code by bundling a broad range of services most often needed by enterprise application developers.