Security
Kerberos is a network authentication protocol that uses encryption for authentication of client-server applications. Kerberos provides advantages for users and system administrators, including the following:
Before attempting to configure Kerberos for jConnect 6.0, make sure you have the following:
To enable Kerberos login with jConnect, use the following procedure.
Configuring Kerberos for jConnect
For more information on the REQUEST_KERBEROS_SESSION and SERVICE_PRINCIPAL_NAME properties, see Chapter 2, "Programming Information" For more information on the GSSMANAGER_CLASS property, see GSSMANAGER_CLASS connection property
When using Kerberos, jConnect relies on several Java classes that implement the Generic Security Services (GSS) API. Much of this functionality is provided by the org.ietf.jgss.GSSManager class.
Java allows vendors to provide their own implementations of the GSSManager class. Examples of vendor-supplied GSSManager implementations are those provided by Wedgetail Communications and CyberSafe Limited. Users can configure a vendor-written GSSManager class to work in a particular Kerberos environment. Vendor-supplied GSSManager classes may also offer more interoperability with Windows than the standard Java GSSManager class provides.
Before using a vendor-supplied implementation of GSSManager, be sure to read the vendor documentation. Vendors use system property settings other than the standard Java system properties used for Kerberos and may locate realm names and Key Distribution Center (KDC) entries without using configuration files.
You can use a vendor implementation of GSSManager with jConnect by setting the GSSMANAGER_CLASS connection property. There are two ways to set this property:
Class.forName().newInstance()
and
casts the returned object as a GSSManager class.
In either case, the application CLASSPATH variable must include the location of the classes and .jar files for the vendor implementation.
If you do not set the GSSMANAGER_CLASS connection
property, jConnect uses the org.ietf.jgss.GSSManager.getInstance method
to load the default Java GSSManager implementation.
When you use the GSSMANAGER_CLASS connection property to pass in a fully qualified class name, jConnect calls the no-argument constructor for the GSSManager. This instantiates a GSSManager that is in the default configuration for the vendor implementation, so you do not have control over the exact configuration of the GSSManager object. If you create your own instance of GSSManager, you can use constructor arguments to set configuration options.
First, jConnect checks the value of GSSMANAGER_CLASS for a GSSManager class object to use in Kerberos authentication.
If the value of GSSMANAGER_CLASS has been set to a string instead of a class object, jConnect uses the string to create an instance of the specified class and uses the new instance in Kerberos authentication.
If the value of GSSMANAGER_CLASS is set to something that is neither a GSSManager class object nor a string, or if jConnect encounters a ClassCastException, jConnect throws a SQLException indicating the problem.
The following examples illustrate how to create your own instance of GSSManager and how to let jConnect create a GSSManager object when the GSSMANAGER_CLASS connection property is set to a fully qualified class name. Both examples use the Wedgetail GSSManager.
Example: Creating your own instance of GSSManager
GSSManager gssMan = new com.dstc.security.kerberos.gssapi.GSSManager();
Properties props = new Properties();
props.put("GSSMANAGER_CLASS", gssMan);
Connection conn = DriverManager.getConnection (url, props);
Example: Passing a string to GSSMANAGER_CLASS
String gssManClass = "com.dstc.security.kerberos.gssapi.GSSManager";
Properties props = new Properties();
props.put("GSSMANAGER_CLASS", gssManClass);
Connection conn = DriverManager.getConnection (url, props);
This section provides suggestions for setting up the environment to use jConnect 6.05 with three different implementations of Kerberos:
Before reading this section, see the white paper on
setting up Kerberos. The URL for this document can be found in the
jConnect for JDBC Release Bulletin.
Specify a Data Encryption Standard (DES) key when creating a principal to be used by Java in the CyberSafe KDC. The Java reference implementation does not support Triple Data Encryption Standard (3DES) keys.
You can use 3DES keys if you are using CyberSafe GSSManager
with a CyberSafe KDC and have set the GSSMANAGER_CLASS
property.
CyberSafe Kerberos does not use a krb5.conf configuration file. By default, CyberSafe uses DNS records to locate KDC address mapping and realm information. Alternately, CyberSafe locates KDC address mapping and realm information in the krb.conf and krb.realms files, respectively. Refer to CyberSafe documentation for more information.
If you are using the standard Java GSSManager implementation, you must still create a krb5.conf file for use by Java. The CyberSafe krb.conf file is formatted differently from the krb5.conf file. Create a krb5.conf file as specified in the Sun manual pages or in the MIT documentation. You do not need a krb5.conf file if using the CyberSafe GSSManager.
For examples of the krb5.conf file, see white paper on setting up Kerberos. The URL for this document can be found in the jConnect for JDBC Release Bulletin.
When using CyberSafe client libraries on Solaris, make sure your library search path includes the CyberSafe libraries before any other Kerberos libraries.
Specify a DES key when creating a principal to be used by Java in the MIT KDC. The Java reference implementation does not support 3DES keys.
If you plan to use only the standard Java GSSManager implementation,
specify an encryption key of type des-cbc-crc
or des-cbc-md5
.
Specify the encryption type as follows:
des-cbc-crc:normal
Here normal
is the type
of key salt. It may be possible to use other salt types.
If you are using Wedgetail GSSManager,
you can create principals in an MIT KDC of type des3-cbc-sha1-kd
.
SSO using the Java reference implementation is available only for Windows 2000 and Windows XP clients, not for Windows NT clients using Microsoft Active Directory. However, SSO is possible for NT clients using a vendor-supplied GSSManager such as that provided by CyberSafe.
Make sure that you have set up accounts in Active Directory for your user principals (the users) and service principals (the accounts that represent your database servers). Your user principals and service principals should both be created as 'Users' within Active Directory.
If you intend to use the Java reference GSS Manager implementation, you must use DES encryption for both user and service principals.
Setting DES encryption
If you plan to use the Java reference implementation to set up an SSO environment on Windows 2000 clients, you may need to modify the Windows Registry according to instructions specified at the following URL:
http://support.microsoft.com/default.aspx?scid=kb;en-us;308339.
On Windows, the Kerberos configuration file is called krb5.ini. Java looks for krb5.ini by default at C:\WINNT\krb5.ini. Java allows you to specify the location of this file. The format of krb5.ini is identical to that of krb5.conf.
For examples of the krb5.conf file, see white paper on setting up Kerberos. The URL for this document can be found in the jConnect for JDBC Release Bulletin.
For more information on Kerberos for Microsoft Active Directory, see the following document:
www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp
The following two commented code samples are provided in the jConnect-6_0/sample2 directory to illustrate how to establish a Kerberos connection to Adaptive Server Enterprise:
To run the ConnectKerberos.java sample application, use the following procedure.
Running ConnectKerberos.java
java ConnectKerberos
select 1
java -Djava.security.krb5.realm=your_realm -Djava.security.krb5.kdc=your_kdc ConnectKerberos
java -Dsun.security.krb5.debug=true ConnectKerberos
java IsqlApp -S jdbc:sybase:Tds:hostName:portNum -K service_principal_name -F path_to_JAAS_login_module_config_fileFor details on using IsqlApp, see
Table 3-1 shows combinations of KDCs, GSS libraries, and platforms on which Sybase has successfully established a connection to Adaptive Server Enterprise. The absence of any particular combination does not indicate that a connection cannot be established with that combination. Interoperability testing is ongoing, and you can find the most recent status at the jConnect for JDBC Web site:
http://www.sybase.com/products/middleware/jconnectforjdbc
| Client platform | KDC | GSSManager | GSS C librariesa | ASE platform |
|---|---|---|---|---|
| Solaris 8b | CyberSafe | Java GSS | CyberSafe | Solaris 8 |
| Solaris 8 | Active Directoryc | Java GSS | CyberSafe | Solaris 8 |
| Solaris 8 | MIT | Java GSS | CyberSafe | Solaris 8 |
| Solaris 8 | MIT | Wedgetail GSSd | MIT | Solaris 8 |
| Solaris 8 | CyberSafe | Wedgetail GSSe | CyberSafe | Solaris 8 |
| Windows 2000 | Active Directory | Java GSS | CyberSafe | Solaris 8 |
| Windows XP | Active Directory | Java GSSf | CyberSafe | Solaris 8 |
| a. These are the libraries that Adaptive Server Enterprise is using for its GSS functionality.b. All Solaris 8 platforms in this table are 32-bit.c. All Active Directory entries in the table refer to an Active Directory server running on Windows 2000. For Kerberos interoperability, Active Directory users must be set to "Use DES encryption types for this account."d. Used Wedgetail JCSI Kerberos 2.6. The encryption type was 3DES.e. Used Wedgetail JCSI Kerberos 2.6. The encryption type was DES.f. Java 1.4.x has a bug which requires that clients use System.setProperty("os.name", "Windows 2000"); to ensure that Java can find the in-memory credential on Windows XP clients. | ||||
Sybase recommends that you use the latest versions of these libraries. Contact the vendor if you intend to use older versions or if you have problems with non-Sybase products.
The standard Java GSS implementation provided by Sun supports only DES encryption. If you intend to use the 3DES, RC4-HMAC, AES-256, or AES-128 encryption standards, you must use the CyberSafe or Wedgetail GSSManagers.
Refer to the respective documentation for more information about Wedgetail and CyberSafe.
This section documents issues to consider when troubleshooting Kerberos security.
Consider the following when troubleshooting problems with Kerberos security:
-Dsun.security.krb5.debug=true
For further information on troubleshooting JAAS and the Java GSS API, refer to the following link:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/tutorials/Troubleshooting.html
The following documents provide additional information on Kerberos security.
| Copyright (C) 2005. Sybase Inc. All rights reserved. |
| |