Connecting to Virtual DataPort Using Kerberos Authentication

The Denodo JDBC driver supports the Kerberos authentication protocol. However, to use it you need to add certain properties to the connection. If not, even if the Virtual DataPort server is configured to use Kerberos authentication, the client will still use standard authentication.

The tables below list the driver properties you have to set when creating the JDBC connection.


Kerberos Authentication with User and Password

This is the easiest option to set up. With this option, the driver will request a ticket-granting ticket (TGT) to the Active Directory and send it to the Server. This is valid for standalone applications that always use the same credentials to connect to Denodo.

Driver properties for “User/password” authentication with Kerberos
Property Value
useKerberos true
debug

true

Remove this property if there are no issues with the Kerberos authentication

user and password User name and password of the user. When using a JDBC client such as DbVisualizer, you can enter the credentials in the “User name” and “password” boxes, instead of providing them as a property.

Using Kerberos Constrained Delegation

The Denodo driver supports Kerberos constrained delegation. This allows the Denodo server to obtain service tickets to a restricted list of other services after the client has presented a service ticket.

Driver properties to pass the Kerberos credential as an object
Property Value
useKerberos true
userGSSCredential Java object of the class org.ietf.jgss.GSSCredential

In the driver property userGSSCredential you have to pass a GSSCredential object. The following sample code shows how to do this:

GSSCredential userCredential = ...;
Driver driver = (Driver) Class.forName("com.denodo.vdp.jdbc.Driver").newInstance();
Properties properties = new Properties();
properties.put("userGSSCredential", userCredential);
Connection conn = driver.connect("jdbc:vdb://denodo1.acme.com:9999/customer?userAgent=myApplication", properties);

Using the Kerberos Credentials of the System to Connect to Denodo

With this option, the driver will obtain the Kerberos credential of the user that launches the application and use it to connect to Denodo.

Driver properties to obtain the Kerberos credential from the ticket cache of the system “Windows Single Sign-On (SSO)”
Property Value
useKerberos true
debug

true

Remove this property if there are no issues with the Kerberos authentication

useTicketCache true
renewTGT true

The property requestCredDeleg is no longer required (it was required before the update Denodo 6.0 update 20170515). Instead, use userGSSCredential. This property was necessary if the user account of the Virtual DataPort server in the Active Directory is configured with constrained delegation.


Using the Kerberos Credentials Stored in a Ticket Cache

With this option, the driver will obtain the Kerberos credential from a Kerberos credential cache.

Driver properties to obtain the Kerberos credential from a ticket cache file
Property Value
useKerberos true
debug

true

Remove this property if there are no issues with the Kerberos authentication

useTicketCache true
renewTGT true
ticketCache Path to the Ticket cache file

Before using this authentication mode, you need to generate a “ticket cache file” on the host where the JDBC application will run. That is, manually obtain and cache on a file a ticket-granting ticket (TGT). To do this, open a command line and execute the following:

%JAVA_HOME%\kinit.exe -f -c "<DENODO_HOME>\conf\vdp-admin\ticket\cache"

The option -f requests the Key Distribution Center (KDC) to return “forwardable” tickets.

With previous versions of the JDBC driver you had to indicate the property serverPrincipal. In Denodo 6.0, this property is no longer necessary because the driver obtains the principal name from the Server.

When the Client Application Does Not Belong to the Domain

Applications that want to connect to Denodo using Kerberos authentication need information about the Active Directory domain. If the client application runs on a host that is part of an Active Directory domain, usually you do not have to do anything because the application obtains this information from the environment. However, if the client is not part of the domain, you need to provide this information. To do this, you need to obtain a krb5.conf/ini file.