|
|
|
|
Java applications, applets, and servlets exploit DB2 security mechanisms in the usual manner. Use of Java-based applications, regardless of whether the Java code executes as an application, applet, or servlet, requires that a userid or authorization ID be passed to DB2. This DB2 rule applies to Java code and execution environments as it would with any other DB2 application.
There is a considerable difference when you use the DB2 for OS/390 JDBC driver as you do not use the userid/password specified on the connect URL. On OS/390, users are authenticated at the point of entry to the system, which happens long before a JDBC getConnection call. The authentication is performed by the application providing the access (for example, TSO, Web server, DDF, CICS). Also, if the DB2 access originates from a multiuser address space, the DB2 for OS/390 CLI (used by the JDBC driver) must be set up to use RRS attach. If Call Attach is used, all originating threads access DB2 with the same authorization ID, which comes from the address space.
Beyond the DB2 DBMS security considerations, there is a unique aspect of the Java language that influences the configuration or implementation approach you use to access DB2. Specifically, there is a security model for Java applets that has two rules:
This security model imposes stringent limitations on the use of Java applets to fully exploit the client workstation or to fully exploit a distributed enterprise data architecture. To enable Java applets access to DB2 data on remote platforms such as DB2 for OS/390 requires a special implementation approach for Java applets.
To access multiple server platforms and use the client browser local resources such as file transfer, copy/paste, and local print capability, a "signed" (or trusted) applet must be used. A signed applet allows you to implement a solution where you maintain control over the applets. With a signed applet, you must indicate whether you trust that an applet downloaded to your browser will not cause harm if it connects to remote servers or uses local client platform computer resources. A signed applet is used to determine the developer or owner of the Java code you are about to execute. As the browser user, you have an option to deny execution of code for unknown or unreliable sources.
Signed Java Applets
To develop and implement access to DB2 for OS/390 with a signed applet, you obtain a security certificate from a CA. The certificate includes several pieces of information, such as the name of the owner, the name of the issuer, the serial number, the finger or thumb print, and the expiration date. The purpose of the certificate is to vouch for the fact that the applet was produced by the owner rather than to guarantee its reliability.
To implement the signed applet, you have to embed the certificate in a compressed *.JAR or *.CAB file where the applet is stored. This process is known as "signing" the applet.
The format of the compressed file differs according to the Web browser used. For example, both Netscape Navigator and Microsoft Internet Explorer allow Java developers to pack a bunch of classes together into a single archive, vastly improving download speed and decreasing strain on the Web server. Unfortunately, the two broswers use different (but noninterfering) mechanisms for packing the classes together. Navigator looks for a compressed file with a filename extension of .JAR, and Internet Explorer expects to find a compressed file with a filename extension of .CAB.
When this applet is downloaded to a browser that supports signed applets, such as Netscape Navigator 4 or Microsoft Internet Explorer 4, you are presented with a panel that tells you that the applet was signed by the owner. You must indicate whether you trust the downloaded applet not to harm your client browser platform. If you respond in the affirmative that you trust the applet, the applet continues to load.
The browser can verify the certificate from the owner, and the user can be assured of the authenticity of the code and accountability of the developer. For more details about this topic, refer to From Client/Server to Network Computing: A Migration to Java, SG24-2247-00.
Java Applets and RMI
RMI is designed to be a lightweight, efficient Java-to-Java protocol. RMI currently has no security model.
The RMI problems include:
The consensus is that RMI, in its current implementation, should be restricted to secure, cooperative environment such as corporate intranets. Putting an RMI server on the Internet requires an extensive security framework, without which your server is open to intrusions.
However, Sun will include Internet Inter-ORB Protocol (IIOP) in the next iterations of RMI, so that RMI communications will benefit from the security model of CORBA. Initially, only a subset of RMI functionalities will be implemented in the new “RMI over IIOP” API, but Sun is committed to a full implementation. New developments should use RMI for implementing distributed applications.
As of JDK 1.2, Sun is distributing the Java Interface Definition Language (IDL) that allows you to access CORBA services from Java, as well as other CORBA services accessible from RMI. These additions include:
