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).

Start of change An applet can attempt to connect to any TCP/IP port on a server. It does not need 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 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. End of change

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.

Java servlets

Servlets are server-side components that are written in Java, which dynamically extend the functionality of a web server without changing web server code. The IBM WebSphere^® Application Server that ships with IBM HTTP Server for iSeries provides support for using servlets on iSeries systems.

You must use resource security on servlet objects that the server uses. However, applying resource security to a servlet does not sufficiently secure it. Once a web server loads a servlet, resource security does not prevent others from running it too. Consequently, you should 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. In addition, you should control who can run the servlet (mask keywords in the protection directive) through the use of HTTP server groups and access control lists (ACL). Also, you should use the security features provided by your servlet development tools, such as those found in the WebSphere Application Server for iSeries™.

Review these resources to learn more about general security measures for Java:

IBM Developer Kit for Java Java Security.
IBM Toolbox for Java security classes.
Security considerations for Internet browsers.

Java authentication and authorization to resources

IBM Toolbox for Java contains security classes to provide verification of the identity of the user and optionally assign that identity to the operating system thread for an application or servlet that is running on an iSeries system. Subsequent checks for resource security occur under the assigned identity. For more detailed information about these security classes, see IBM Toolbox for Java Authentication Services.

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). To learn more about using the J2SDK, see Java Authentication and Authorization Service.

Securing your Java applications with SSL

You can use Secure Sockets Layer (SSL) to secure communications for iSeries 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 than enabling it for the other applications.

For more information about Secure Sockets Layer administration for Java applications, see these Start of change IBM Systems Software Information Center End of change topics:

IBM Toolbox for Java Secure Sockets Layer (SSL) environment.
IBM Developer Toolkit for Java to make a Java application secure with SSL.