Java Internet security

Java programming is becoming increasingly widespread in today's computing environments. For example, you might be using the IBM Toolbox for Java or the IBM Development Kit for Java on your system to develop new applications. Consequently, you must prepare to deal with the security issues that are associated with Java. Although a firewall is a good defense against most general Internet security risks, it does not provide protection for many risks that using Java presents. Your security policy should include details for protecting your system against three areas of concern for Java: applications, applets, and servlets. Also, you should understand how Java and resource security interact in terms of authentication and authorization for Java programs.

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 which protects 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 should apply the same security rules for application design that you apply with other languages on your iSeries server.

Java applets

Java applets are small Java programs that you can include in your HTML pages. Because applets run on the client, what they do is a concern to the client. However, a Java applet has the potential to access your iSeries server. (An ODBC program or an advanced program-to-program communications (APPC) program that operates on a PC in your network can also access your iSeries.) In general, Java applets can establish a session only with the server from which the applet originated. Therefore, a Java applet can access your iSeries from a connected PC only when the applet came from your iSeries server (such as from your web server).

An applet can attempt to connect to any TCP/IP port on a server. It does not have to talk to a software server that is written in Java. But, for servers 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 server. In this material, the servers described are all iSeries servers. (A server written in Java does not have 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 iSeries server 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 function. When the system processes the requests from applets, it does not use the limited capability value in the profile of the user.

The applet viewer allows you to test an applet on the server system; however, it is not subject to browser security restrictions. Therefore, you should use the applet viewer to test your own applets only, never to run applets from outside sources. Java applets often write to the PC drive of the user, which may allow the applet 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 iSeries server because they appear to the PC to be local drives.
Note:
The behavior described above is generally true for Netscape Navigator and MS Internet Explorer. What actually happens depends on how you configure and manage the browsers that you use.

For Java applets that originate from your iSeries server, you might need to use signed applets. However, you should 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 to configure registered Java programs to use SSL.