Creating a DSN-Less Connection¶
Some ODBC tools support connecting to an ODBC server without using a data source name (DSN). This is known as a DSN-less connection.
This section lists the parameters you have to use to create a DSN-less connection to Virtual DataPort.
DRIVER={DenodoODBC Unicode(x64)};UID=<user account>;PWD=<password of the user>;SERVER=<host name>;DATABASE=<database name>;PORT=9996;SSLmode=prefer;service=;krbsrvname=HTTP;UserAgent=<user agent>;ReadOnly=0;Protocol=7.4-1;FakeOidIndex=0;ShowOidColumn=0;RowVersioning=0;ShowSystemTables=0;ConnSettings=set+i18n+to+us%5fpst%3b;Fetch=100;Socket=4096;UnknownSizes=0;MaxVarcharSize=255;MaxLongVarcharSize=8190;Debug=0;CommLog=0;Optimizer=0;Ksqo=0;UseDeclareFetch=1;TextAsLongVarchar=1;UnknownsAsLongVarchar=0;BoolsAsChar=0;Parse=0;CancelAsFreeStmt=0;ExtraSysTablePrefixes=dd_;LFConversion=1;UpdatableCursors=0;DisallowPremature=0;TrueIsMinus1=0;BI=0;ByteaAsLongVarBinary=0;UseServerSidePrepare=0;LowerCaseIdentifier=0;PreferLibpq=1;GssAuthUseGSS=0;XaOpt=3;UseKerberos=0
DRIVER={DenodoODBC Unicode};UID=<user account>;PWD=<password of the user>;SERVER=<host name>;DATABASE=<database name>;PORT=9996;PWD=;SSLmode=prefer;service=;krbsrvname=HTTP;UserAgent=<user agent>;ReadOnly=0;Protocol=7.4-1;FakeOidIndex=0;ShowOidColumn=0;RowVersioning=0;ShowSystemTables=0;ConnSettings=set+i18n+to+us%5fpst%3b;Fetch=100;Socket=4096;UnknownSizes=0;MaxVarcharSize=255;MaxLongVarcharSize=8190;Debug=0;CommLog=0;Optimizer=0;Ksqo=0;UseDeclareFetch=1;TextAsLongVarchar=1;UnknownsAsLongVarchar=0;BoolsAsChar=0;Parse=0;CancelAsFreeStmt=0;ExtraSysTablePrefixes=dd_;LFConversion=1;UpdatableCursors=0;DisallowPremature=0;TrueIsMinus1=0;BI=0;ByteaAsLongVarBinary=0;UseServerSidePrepare=0;LowerCaseIdentifier=0;PreferLibpq=1;GssAuthUseGSS=0;XaOpt=3;UseKerberos=0
About the examples above:
To use the examples above, replace
<user account>
,<password of the user>
,<host name>
and<database name>
and<user agent>
. If you changed the default ODBC port, replace 9996 with the actual ODBC port of Virtual DataPort.Note that the value of the property
DRIVER
has to be{DenodoODBC Unicode}
or{DenodoODBC Unicode(x64)}
depending on if you are creating the connection from a 32-bit client or a 64-bit one, respectively.When using DSN-less connections you may not be able to connect if the password contains the following characters four:
%
,{
,}
and+
. If so you may need to escape these characters:%
as%25
,+
as%2B
,{
as%7B
and}
as%7D
.
Note
Do not leave any space between the names of parameters, the equal symbol, the values, the semicolon, etc.
Use Kerberos Authentication¶
To connect to Virtual DataPort with Kerberos authentication, check with the administrator of Denodo that Kerberos is configured on Virtual DataPort. Otherwise, the connection with the Kerberos protocol will fail.
To use Kerberos authentication in a DSN-less connection use the previous general templates with the following considerations:
Remove the parameters
UID
andPWD
.Set parameter
UseKerberos
to1
.The value of the property
SERVER
has to be the fully qualified domain name of the Denodo server. That is, if in the Kerberos configuration of the Denodo server the field Server principal isHTTP/denodo-prod.subnet1.contoso.com@CONTOSO.COM
, enterdenodo-prod.subnet1.contoso.com
.Usually, the default value of
krbsrvname
is correct. This value has to match the “service class” of the Service Principal Name of the Server. For example, if in the field Server Principal of the Kerberos settings of the Server, you haveHTTP/denodo1.contoso.com@CONTOSO.COM
, the value of krbsrvname has to be HTTP.
Use OAuth Authentication¶
To connect to Virtual DataPort with OAuth authentication, check with the administrator of Denodo that OAuth is enabled on Virtual DataPort. Otherwise, the connection with the OAuth protocol will fail.
Denodo ODBC driver provides two paths to connect to Denodo using OAuth. Depending on the one you choose you have to add certain parameters or others to the connection string.
Path #1: OAuth 2.0 Authentication providing access token
The client application obtains an OAuth access token and passes it to the driver. Then, the driver uses this token to connect to Virtual DataPort, instead of using user/password.
This path is meant to be used by client applications that have the ability to obtain access tokens to connect to Virtual DataPort. This client application can obtain this access token for itself or on behalf of the end user of the application.
To use this method, do this:
Add these parameters to the DNS-less connection string:
UseOAuth2=1
: enable OAuth 2.0 authenticationAccessToken
: the value is the access token obtained by the client application.
Remove the parameters
UID
andPWD
.
Path #2: OAuth 2.0 by Resource Owner Password Credentials
If the client application does not have the ability of obtaining OAuth tokens, the driver can obtain one on behalf of the application, if the Identity Provider of your organization supports the Resource Owner Password Credentials OAuth flow.
In this case, you configure the connection with information about the Identity Provider. That is, the URL to request tokens to the Identity Provider, client id and client secret of the application you registered on the Identity Provider, etc.
To use this method, do this:
Provide a value for the parameters
UID
andPWD
. For these, provide the credentials in the Identity Provider to obtain an access token.Add the following parameters to the connection string:
Property |
Meaning |
---|---|
UseOAuth2 |
Set to |
TokenEndpoint |
URL exposed by the OAuth server and used to request the access_token. For instance |
ClientId |
Application’s Client ID. Usually, you obtain this when registering the client application in the Identity Provider. |
ClientSecret |
Application’s Client secret. |
Scope |
Space-delimited list of requested scope permissions. |
ExtraParams |
Additional parameters that will be added to the body of the HTTP requests the driver will send to obtain OAuth tokens. The syntax of the value of this parameter is |
UseIdToken |
If |
OAuthSSLVerify |
If |