Java Internet security

Java applications

As a language, Java has some characteristics that protect Java programmers from unintentional errors that can cause integrity problems. (Other languages that are commonly used for PC applications, such as C or C++, do not protect the programmers from unintentional errors as strongly as Java does.) For example, Java uses strong typing, the strict enforcement of type rules with no exceptions, to protect the programmer from using objects in unintended ways. Java does not allow pointer manipulation, which protects the programmer from accidentally going outside the memory boundaries of the program. From an application development perspective, you can view Java as you do other high-level languages. You need to apply the same security rules for application design that you apply with other languages on your system.

Java applets

Java applets are small Java programs that you can include in HTML pages that run on the client but have the potential to access your i5/OS operating system. An Open Database Connectivity (ODBC) program or an advanced program-to-program communications (APPC) program that operates on a PC in your network can also potentially access your operating system when, for example, your system is being used to serve applications or is being used as a Web server. In general, Java applets can establish a session only with the i5/OS operating system from which the applet originated. Therefore, a Java applet can access your i5/OS operating system from a connected PC only when the applet comes from that i5/OS operating system.

An applet can attempt to connect to any TCP/IP port on a system. It does not need to talk to a software server that is written in Java. But, for systems that are written with the IBM® Toolbox for Java, the applet must provide a user ID and password when it establishes connections back to the system. In this material, the systems described are all i5/OS operating systems. (A Java application server does not need to use the IBM Toolbox for Java.) Typically, the IBM Toolbox for Java class prompts the user for a user ID and password for the first connection.

The applet can perform functions on the i5/OS operating system only if the user profile has authorization to those functions. Therefore, a good resource security scheme is essential when you begin to use Java applets to provide new application functions. When the system processes the requests from applets, it does not use the limited capability value that is specified in the user profile.

The applet viewer allows you to test an applet on the i5/OS operating system; however, it is not subject to browser security restrictions. Therefore, you need to use the applet viewer to test only your own applets, never to run applets from outside sources. Java applets often write to the PC drive of the user, which might provide the applet with the opportunity to perform a destructive action. However, you can use a digital certificate to sign a Java applet to establish its authenticity. The signed applet can write to the PC's local drives, even though the default setting for the browser prevents it. The signed applet can also write to mapped drives on your system because they appear to the PC to be local drives.

For Java applets that originate from your system, you might need to use signed applets. However, you need to instruct your users, in general, not to accept signed applets from unknown sources.

Beginning with V4R4, you can use the IBM Toolbox for Java to set up a Secure Sockets Layer (SSL) environment. You can also use the IBM Developer Toolkit for Java to make a Java application secure with SSL. Using SSL with your Java applications ensures encryption of the data, including the user IDs and passwords that pass between the client and server. You can use Digital Certificate Manager (DCM) to configure registered Java programs to use SSL.

Java servlets

Servlets are server-side components that are written in Java, which dynamically extend the function of a Web server without changing Web server code. The IBM WebSphere® Application Server that is included in IBM Web Enablement for i5/OS provides support for using servlets on the i5/OS operating systems.

You must use resource security on servlet objects that the system uses. However, applying resource security to a servlet does not sufficiently secure it. After a Web server loads a servlet, resource security does not prevent others from running it too. Consequently, you need to use resource security in addition to using HTTP server security controls and directives. For example, do not allow servlets to run under the profile of the Web server only. You also need to use the security features provided by your servlet development tools, such as those found in the WebSphere Application Server for i5/OS.

Java authentication and authorization to resources

IBM Toolbox for Java contains security classes to provide verification of the identity of the user and optionally to assign that identity to the operating system thread for an application or servlet that is running on an i5/OS operating system. Subsequent checks for resource security occur under the assigned identity.

The IBM Developer Kit for Java provides support for the Java Authentication and Authorization Service (JAAS), which is a standard extension to the Java 2 Software Development Kit (J2SDK), Standard Edition. Currently, J2SDK provides access controls that are based on where the code originated and who signed the code (code source-based access controls).

Securing your Java applications with SSL

You can use Secure Sockets Layer (SSL) to secure communications for i5/OS applications that you develop with IBM Developer Kit for Java. Client applications that use IBM Toolbox for Java can also take advantage of SSL. The process for enabling SSL for your own Java applications is somewhat different from the process for enabling SSL for the other applications.