Access Control Requirements for the Java Platform

As we saw in Chapter 2, A Quick Tour of the Java Platform, one can develop many different categories of Java programs and deploy them in different environments. The access control requirements for each category of programs are quite different and better understood in the context of these programs.

Applets within a Web Browser

Java applets are compiled Java programs that get downloaded by a Web browser and executed within the JVM embedded in the browser. Such programs offer the benefit of a more dynamic and richer user interface, quicker validation of input and faster response time to the user, for a lot of processing can be done locally. However, there are significant security risks in allowing code downloaded from the Internet unrestricted access to all the resources that a browser can access, which is usually pretty much everything the user running the browser owns.

Typically, an untrusted applet should not be able to:

• Read or write arbitrary files on the local file-system.

• Execute arbitrary programs on the local machine.

• Establish a network connection to any machine. An exception is the machine from which the applet code was downloaded.

• Terminate the JVM running the applet.

• Access memory objects created by other applets running within the same JVM.

• Read or modify the value of certain system properties that may reveal too much information about the machine and the user running the JVM.

• Change the security privileges assigned to itself or other code.

This is not a comprehensive list but gives us an idea of what is expected from the Java platform to run applets. Essentially, as it is popularly known, we expect applets to run within a sandbox.

In addition, it should be possible for the user to specify privileges, such as write permission to a specific directory, to particular applets or applets downloaded from specific sites. In other words, the user should be able to define the boundaries of the sandbox.

The important thing to remember is that the applet security is not about all or nothing. It should be possible to set up the system so that access permissions to specific resources can be granted selectively. In fact, the security model adopted by early Java systems defined a fairly rigid boundary around applets and was aptly criticized for doing so.

Standalone Java Programs

Not all Java programs are applets. A good number of desktop applications, to be started by the user by specifying the program class name at the command prompt or clicking the program icon, are written using Java. It is imperative that the Java access control model does not restrict these programs in any way, other than the restrictions placed by the underlying operating system and any other system it may rely upon.

Besides user-initiated desktop applications, standalone Java programs may also run as daemon programs, exposing server functionality through RMI server or TCP/IP server socket interfaces.

Client programs that use RMI to invoke methods on an RMI server fall under a slightly different category. Such programs download stub code from potentially untrusted sources and must restrict the actions performed by the downloaded stub code.

There may be scenarios when a standalone program supports multiple users, either one at a time or concurrently through RMI or Socket clients. It should be possible for such programs to restrict access to resources based on user identity and policies specified by the program. This capability was first introduced as a standard extension called JAAS (Java Authentication and Authorization Services) and has now been made part of J2SE v1.4 SDK. We have already come across this during our tour of the Java access control features. The APIs to let a user login to a Java program, specify a user management module and principal base access rules in the policy files are all part of JAAS.

JAAS not only provides the API for user identity and authentication capability but also defines a framework for supporting multiple different authentication technologies toward this end. Part of this framework is essentially the Java version of industry standard PAM (Pluggable Authentication Module) framework for integrated login solution, promoted by OSF (Open Software Foundation). Here is a brief description of PAM taken from the original OSF press release of December 11, 1995.

Originally developed by SunSoft as part of its Solaris operating environment, PAM integrates multiple low-level authentication mechanisms by plugging them into applications at runtime via a single high-level application programming interface (API). The authentication mechanisms, which can be either standalone operating system or network mechanisms, are encapsulated as dynamically loadable shared software modules.

The software modules can be installed by system administrators independently of applications, and executed by applications depending on the system configuration. In this way, PAM provides administrators with the flexibility of selecting one or multiple authentication technologies without modifying the applications. PAM also insulates application developers from evolutionary improvements to authentication technologies, while at the same time allowing deployed applications to avail themselves of those improvements.

Although technically feasible, examples of utilizing Java access control to support multi-users standalone Java programs are rare. This is partly because most of the attention for multi-user programs has been around the J2EE platform and partly because this capability itself is quite new.

Components within the J2EE Platform

As we noted in Chapter 2, A Quick Tour of the Java Platform, there are two kinds of J2EE containers: Web containers for Servlet/JSP-based Web applications and EJB containers for EJB-based applications. Both kinds of applications require the ability to authenticate clients and authorization of resources based on the identity of the current client. As we noted earlier, this capability is made available via JAAS.

Besides the basic capability of authenticating users and authorizing operations, J2EE platform has a number of other requirements. We cover these in subsequent chapters.