JDBC Drivers and Web Security

Mukul is a system architect at Digital Focus. He can be contacted at [email protected].

The Java Database Connectivity (JDBC) specification is an interface for database programming. At present, there are at least two dozen commercially available JDBC implementations. As I described in "Examining JCBC Drivers" (DDJ, January 1998), JDBC driver vendors have considerable freedom in their implementations of the JDBC specification. Still, to be JDBC compliant, JDBC drivers must support the ANSI SQL 2 Entry Level standard, pass JavaSoft conformance tests, and fall into one of four categories as defined by JavaSoft:

• Type I, JDBC/ODBC Bridge.
• Type II, Native-API, Partly Java Driver.
• Type III, Net-Protocol, All Java Driver.
• Type IV, Native-Protocol, All Java Driver.

I won't detail the differences between these four categories, referring you instead to my January 1998 article. In this article, I'll focus on the security features offered by various driver vendors, and describe how they fit in with the various application deployment architectures.

Java, Security, and the Web

Although security is not officially part of the JDBC specification, it is nonetheless critical for many database applications deployed on the Web. The success of online trading, shopping marts, and sensitive retail transfer information (credit cards, bank accounts, social-security numbers, and the like) over an inherently insecure medium (the Internet) depends on reliable security. Consequently, JDBC driver vendors are beginning to offer security features such as encryption and authentication, which can be used by applications to deliver secure and reliable services.

Applications can be deployed on the web in various configurations.

• Client behind a firewall. Firewall security is an integral part of security infrastructure at many organizations. This especially holds true if the organization allows Internet access. Typically, organizations put a firewall between the private trusted network and the public Internet. In this case, access would be allowed only to certain protocols (HTTP) and at a specific port. Thus a client behind a firewall would be able to connect through the firewall, if it uses these allowed protocols. Figure 1 shows this configuration. If the JDBC client speaks a certain protocol, it would be able to connect to the web-server host only if it supports tunneling of that protocol through HTTP packets, assuming the firewall on the client allows HTTP traffic to get through; Sybase's jConnect, for example, uses Tabular Data Stream format (TDS). (For more on Java and secure tunneling, see "Java Q&A," by Kenneth Golomb and Thomas Sorgie, DDJ, June 1998.) The other possibility would be for the client-side firewall to allow the protocol (TDS, SqlNet, and so on) to get through.
• Client outside of a firewall. Another commonly used configuration; the client accesses the Internet without going through a firewall. In this case, the client can use vendor-specific protocols to connect to the server host. The server could be running on the same host as the web server that served the applet or it could be on a different host. The server could be a gateway server (in case of Type IV drivers) or a JDBC server (in case of Type III drivers). The JDBC server could be set up on a host different from the web server, in which case it would be necessary to run a proxy server on the web-server host. This proxy would pass through JDBC client requests to the JDBC server and response from the server to the client; see Figure 2.
• Client in an intranet. A private trusted network would have no firewalls installed. Examples would be department- or company-wide intranets that are sealed off from public networks (such as Internet). In this configuration, the client would connect to the web-server host, which also runs the gateway server for Type IV drivers, the proxy server for Type III drivers, or runs the JDBC server for Type III drivers.
• The role of a gateway for a Type IV driver is different from that for a Type III driver. A gateway for a Type IV driver is actually a connection server that manages database connections. In case of a Type III driver, the gateway is basically a proxy for the actual connection server. A Type IV driver can only connect to the web server from which it was downloaded so it can open a database connection to the web-server host. Consequently, the database server would need to be installed on the same host as the web server. The gateway gets around this limitation by taking the role of a connection server.

These are some common deployment configurations. Many configurations are possible, given existing infrastrucure, application requirements, IT standards employed by the organization, and other factors.

The Secure Sockets Layer Protocol

Encryption and authentication are integral parts of security, and the Secure Sockets Layer (SSL) protocol supports both of these features. SSL is the dominant protocol for encrypting general communications between browsers and servers. It is built into both the Netscape and Microsoft browsers. The SSL protocol operates at the TCP/IP transport layer, one level below application-specific protocols such as NNTP (news), HTTP (web), and SMTP (mail). Any program that uses TCP can be modified to use secure SSL connections by making a few source code changes. Figure 3 shows the SSL protocol stack.

The main trade-off for putting SSL at the transport layer is that it is not specifically tuned for HTTP and therefore may not always be efficient for web browsing. A minor limitation is that an SSL connection must use a dedicated TCP/IP socket. SSL uses cryptographic principles such as digital envelope, signed certificates, and message digests. An important feature of SSL is flexibility with regard to choices of encryption algorithm (symmetric algorithms like DES, 3DES, RC2, RC4), message digests (MD5, SHA), and authentication methods (RSA public keys and certificates or Diffie-Hellman key exchange).

The combination of encryption algorithm, message-digest function, and authentication is known as a "cipher suite." The Netscape browser supports more than 30 cipher suites. Likewise, JDBC drivers support various cipher suites.

When an SSL client first makes contact with a server, the two negotiate a common cipher suite. In general, the two try to pick the strongest encryption methods that they have in common.

When an SSL connection is in place, all browser-to-server and server-to-browser communications are encrypted including the URL of the requested document, contents of the requested document, and contents of the HTTP header.

Table 1 summarizes the drivers and shows what features are offered by each vendor.

Tengah/JDBC

Weblogic's Tengah/JDBC is a Type III implementation of JDBC for use with Java applets and applications. It includes features such as authentication and encryption (through Tengah SSL), access to name services (NIS, NDS, and the like), access-control lists, HTTP, IIOP tunneling, and proxy support.

Tengah/JDBC secures networked applications with optional encryption, authentication, and authorization based on RSA SSL, X.509 certificates, and access-control lists. It provides encryption and authentication through Tengah SSL, which is Weblogic's implementation of SSL Version 3. Tengah SSL uses RSA as the key exchange method. It supports both server-to-client and two-way authentication. User authentication is provided through X.509 certificates. Tengah supports message protocols such as t3 (Tengah's native protocol, which uses TCP sockets) and HTTP. The SSL layer permits these protocols to be secured as t3s and HTTPS. When a t3s connection is opened, a certificate exchange occurs that guarantees the server's identity. Thereafter, communications are encrypted. In the case of an applet, the certificate used to establish the HTTPS connection is used for the applet's t3s connection.

Tengah uses the Java Naming and Directory Interface (JNDI) to provide access to underlying directory-naming services that support LDAP, such as Novell's NDS and Sun's NIS.

It uses the JDK 1.1 ACL Principal, Group, Permission, Acl, and AclEntry interfaces in its implementation of ACL. Tengah's support for ACLs follows the Javasoft javasecurity.acl specification. The ACL support built into Tengah, the Weblogic Realm, depends upon users having an entry in a list that grants or denies permission to access a particular service. Tengah organizes Users, Groups, Permissions, and Acls into Realms which map to Principal, Group, Permission, Acl, and AclEntry. A Tengah application can set up its own ACL, and its own Realm. The Weblogic Realm, which is supplied as a Tengah service, provides ACLs for Tengah.

Tengah also supports HTTP and IIOP tunneling; thus, a client behind a firewall could connect to the Tengah server through these tunneling mechanisms.

SequeLink

SequeLink, Intersolv's Type III driver, provides features such as multiple levels of security, encryption, and a lightweight Java proxy.

SequeLink supports six levels of security: DBMS system authentication, host system authentication, data encryption, application authentication, ReadOnly, and Autocommit.

SequeLink interfaces with the host system security provided by the OS system security (Windows NT or UNIX, for instance), delivering an additional layer of user authentication for access to the system services. SequeLink does not support JNDI in the current version. SequeLink uses encryption on-the-wire for all data and user account information (including UID/PWD). The current version does not use SSL. Application authentication allows system administrators to determine specific client applications that can access specific SequeLink services. Client applications pass a specific key that the SequeLink server then validates as an authenticated server configuration. Certain apps (query tools) can thus be restricted to read-only while others can have full write and update permissions.

SequeLink offers the unique ReadOnly and Autocommit filters. When Autocommit is switched on, the server begins and commits each statement immediately, regardless of application setting. When ReadOnly is switched, the server processes only SQL SELECT statements and does not send statements such as INSERT, UPDATE, and DELETE to the database engine. This feature can be useful for organizations where custom applications are used for order entry (requiring end users to have write permissions), but the same end users may need to run query tools for decision support or data mining. If a user were to accidentally change a value in these other tools, then the entire data could be corrupted.

Another SequeLink feature is its Java proxy, which is essentially a Java application running on the web-server host, its role being that of a pass-through server to the SequeLink JDBC server.

SequeLink does not have HTTP tunneling support in its current version. Clients behind a firewall that allows only HTTP traffic, therefore, would not be able to connect to the server.

JSQL/Ingres

JSQL (Java to SQL) is a Type III driver from Caribou Lake Software for connecting to Ingres databases. It has various components that provide proxy services, authentication, tunneling, and the main server component that connects to database servers. These components are:

• Jsvr, a JDBC connection server.
• Jpass, a proxy server for Jsvr.
• Jtunnel, for HTTP tunneling.
• Jauth, validates username/password on remote computers in network.

Jtunnel is an HTTP tunneling server that tunnels JDBC connections through firewalls and reverse proxy servers. Jtunnel could also be used with a secure HTTP server to provide encryption between the Java client and the web server. Jtunnel comes with a CGI script named "Jcgi" that should be installed on the web-server host if tunneling is required. This script takes the HTTP packet and sends it to Jtunnel, which retrieves the data from the packet and forwards it either to Jpass or to Jsvr depending on the connection URL in the request. Jpass provides pass-through services; Jsvr can be installed on a different host than the web server, and Jpass would relay client requests to Jsvr.

Jauth is the authentication server for authenticating JDBC client connects to the Jsrv connection server. It supports authentication methods such as operating-system authentication (for server OSes), database authentication (Open Ingres only), and remote authentication (server OSes). Jsvr can be configured with an access-control list.

SQL Retriever

SQL Retriever is SCO's server module, with which the SCO JDBC client communicates. The JDBC client allows Java applets or applications to access information from Oracle, Informix, Ingres, Sybase, Interbase, and Progress databases on any UNIX platform.

The driver communicates with the server module, which is installed either on the web server or another host. The driver communicates with the server using Sun RPC (Remote Procedure Call) mechanism. The RPC layer forms a connection using Java sockets. The SQL-Retriever server is a UNIX daemon process. The default configuration for JDBC client and server is that the client gets the port of the server from portmapper and the server is started as root and registers itself with the portmapper. If the server is behind a firewall, the port 111 (used by portmapper) is blocked. In this case, the server can be made to listen on a specific port (start the server with a -l flag, flag should be followed by the port number). At the client side, the port should be specified in the JDBC connect URL, the client then will not use the portmapper, it will go straight to this port. If the client is behind a firewall which allows only HTTP traffic, then the client would not be able to connect to the server.

SQL Retriever's security features include a security manager which lets system administrators control user access to the database or to specific tables in the database, and a proxy RPC-Reflector, which allows servers to be installed on a host other than a web server (it passes through client requests to the server). SQL Retriever does not offer encryption and server-authentication.

jConnect

Sybase's jConnect is a Type IV driver for connecting to the Sybase SQL Server. For connecting to servers using SSL, jConnect Release 3.0 provides a Java servlet that should be installed on the web server that hosts the applet. The web server should support the javax.servlet interfaces, which enables jConnect to support encryption using the web server as the gateway. jConnect uses the TDS-tunnelled HTTP protocol in proxy and firewall configurations; see Figure 4.

With the TDS-tunneling servlet, requests from a client to the back-end server that go through the gateway include a GET or POST command, the TDS session ID (after the initial request), back-end address, and status of the request as query parameters for the request. The TDS stream is contained in the body of the request. Two header fields indicate the length of the TDS stream included in the request packet, and the session ID assigned by the servlet. When the client sends in an initial request (login request), the servlet creates a session ID, strips the HTTP headers and sends the TDS data to the server, gets the results back from the server in TDS format, assembles an HTTP packet (passing the session ID in the header), and sends the packet to the client. Subsequent requests from the client contain that session ID in the header.

Oracle ThinJDBC

ThinJDBC, Oracle's Type IV driver, has a footprint of about 150 KB and provides its own implementation of a TCP/IP version of Oracle's SQLNet/Net8 protocol. This driver only works with TCP/IP-based networks. It supports Oracle databases Versions 7.2 and upward. ThinJDBC does not have proxy support; it can, however, be used with the Oracle Connection manager to achieve three-tier configurations. Since it does not support HTTP tunneling, it will not work with those firewalls that only allow HTTP through. It would work with firewalls that allow SQLNet traffic. The communication between an applet that uses the ThinJDBC driver and the database happens over Java TCP/IP sockets. The connection can only be made if the web browser (where the applet is executing) allows a socket connection to be made. In JDK 1.0.2-based browsers (such as Netscape 3.0), the applet would only be able to open a connection to the host from which it was downloaded. In this case, the database would have to be present on the same host as the web server. With JDK 1.1-based browsers, this restriction does not apply if the applet is signed.

Oracle Connection Manager may be deployed in combination with JDBC applets to provide secure access to Oracle environments. Connection Manager incorporates a Net8 application proxy, which lets system administrators control how a connection request gets routed. Through the use of rules, requests may be filtered based on parameters such as:

• Destination or Origin IP address.
• Oracle System Identifier (SID).
• Data encryption/security preferences.

The ThinJDBC applet can connect to a Connection Manager running on the web-server host and have the Connection Manager redirect the packets to an Oracle server running on a separate host.

Fast Forward

FastForward, a Type IV driver from Connect Software, provides Java clients with direct access to Microsoft SQL Server (all versions) and Sybase SQL Servers (Versions 4, 9, 10, and 11). FastForward works by directly transferring and receiving information from Java to SQL Server using TCP/IP sockets. The format of data passed back and forth is TDS. Version 3.0 offers features such as xencryption and HTTP tunneling through the FastForward Security Proxy. FastForward Proxy is a pure Java application that provides connectivity between clients on the Internet and servers within your network. It also provides HTTP tunneling, compression, and encryption. Proxy uses symmetric private key encryption in 16 rounds with 64-bit key for encryption. It also supports DES.

OPENjdbc

OPENjdbc is I-Kinetics CORBA-based Type III driver. The driver communicates to the DataBroker server through IIOP protocol. The databroker server is based on CORBA, using Iona's Orbix Object Request Broker to provide features such as multithreading, connection pooling, and load balancing. OPENjdbc invokes methods and services defined in the DataBroker's IDL files. Figure 5 illustrates the OPENjdbc architecture.

OPENjdbc driver offers security features such as SSL encryption and authentication (through Orbix SSL) and HTTP tunneling of IIOP. The SSL option is provided through Orbix SSL, which allows Orbix- and Orbix-Web-based applications to be easily retrofitted with SSL security. Orbix SSL replaces the default IIOP protocol with the standardized SSL-IIOP protocol, which is essentially IIOP over secure SSL connections. The SSL option provides authentication using public-key cryptography (RSA, DSS) and encryption using block-encryption methods (DES, RC4).

The DataBroker server need not be on the same host as the web server that served the applet. An IIOP proxy on the web server can route all requests to the databroker. Iona's Wonderwall offers this feature along with its firewall features such as examination, filtering and logging of IIOP requests, HTTP tunneling support, and ACL support.

Conclusion

Security is an important aspect of applications that deal with sensitive data and are deployed on an open medium such as the Internet or an open intranet (no firewall). JDBC driver vendors offer tools which could meet the security needs of these applications. Your choice of software should be made based on factors such as application requirements, deployment configuration, security needs, expandibility, and standards supported by the vendor.

For More Information

WebLogic Inc.
417 Montgomery Street
San Francisco, CA 94104
415-659-2600
http://www.weblogic.com/

Intersolv Inc.
9420 Key West Avenue
Rockville, MD 20850
301-838-5000
http://www.intersolv.com/

Caribou Lake Software Inc.
4780 Beacon Hill Road
St. Paul, MN 55122
612-688-9470
http://www.cariboulake.com/

SCO
425 Encinal Street
P.O. Box 1900
Santa Cruz, CA 95061-1900
408-425-7222
http://www.sco.com/

Sybase Inc.
6475 Christie Avenue
Emeryville, CA 94608
510-922-3555
http://www.sybase.com/

Oracle Corp.
500 Oracle Parkway
Redwood Shores, CA 94065
650-506-7000
http://www.oracle.com/

Connect Software Inc.
81 Lansing Street
San Francisco, CA 94105
415-543-6695
http://www.connectsw.com/

I-Kinetics Inc.
17 New England Executive Park
Burlington, MA 01803
781-270-1300
http://www.i-kinetics.com/

DDJ