You can translate the document:

Overview

Starting in Tableau version 2023.1 its connector SDK provides multi-identity provider configuration capabilities. So the new Denodo JDBC connector (version 1.0.6) takes advantage of this feature to allow customers to configure their own identity provider instance.

In this document, we will provide guidelines to properly configure the Denodo JDBC connector with OAuth authentication for a specific Identity provider.

Note: If you are using a previous version of Tableau you should refer to the following article as this one is focused on Tableau 2023.1 or newer versions: How to update the Tableau Denodo JDBC connector to support OAuth Authentication

Providing custom OAuth configuration file

In order to take advantage of the multi-identity provider capabilities, the connector SDK requires the connector to include, at least, one OAuth configuration file that could be used. Due to this requirement, the Denodo JDBC connector included a configuration for Azure AD but notice that it is only a template to configure your own identity provider, if you select the Azure AD configuration the OAuth authentication field, it will not work.

So the first step would be to create an OAuth configuration file to be used for the OAuth connections. You could use the following content as a template:

<?xml version="1.0" encoding="utf-8"?>
<
pluginOAuthConfig>        
   <
dbclass>denodo_jdbc</dbclass>    

    <oauthConfigId>custom_azure_ad</oauthConfigId>
   
<!-- Dependents on the customer environment.
      In addition clientIdDesktop, clientSecretDesktop and
      redirectUrisDesktop could be redefined when using Tableau Server -->
   
   <
clientIdDesktop>[clientId]</clientIdDesktop>
   <
clientSecretDesktop>[clientSecret]</clientSecretDesktop>      

<redirectUrisDesktop>http://localhost:55555/Callback</redirectUrisDesktop>    
   <
authUri>https://login.microsoftonline.com/[tenantId]/oauth2/v2.0/authorize</authUri>    <tokenUri>https://login.microsoftonline.com/[tenantId]/oauth2/v2.0/token</tokenUri>
   <
scopes>openid</scopes>
   <
scopes>offline_access</scopes>  
   <
capabilities>  
             <
entry>
                   <
key>OAUTH_CAP_REQUIRE_PKCE</key>
                   <
value>true</value>
             </
entry>        
       <
entry>
           <
key>OAUTH_CAP_PKCE_REQUIRES_CODE_CHALLENGE_METHOD</key>
           <
value>true</value>
       </
entry>
       <
entry>
           <
key>OAUTH_CAP_FIXED_PORT_IN_CALLBACK_URL</key>
           <
value>true</value>
       </
entry>
                <
entry>
           <
key>OAUTH_CAP_SUPPORTS_STATE</key>
           <
value>true</value>
       </
entry>  
                <
entry>
           <
key>OAUTH_CAP_SUPPORTS_GET_USERINFO_FROM_ID_TOKEN</key>
           <
value>true</value>
       </
entry>                                   
   </
capabilities>
   <
accessTokenResponseMaps>
       <
entry>
           <
key>ACCESSTOKEN</key>
           <
value>access_token</value>
       </
entry>
       <
entry>
           <
key>REFRESHTOKEN</key>
           <
value>refresh_token</value>
       </
entry>                
       <
entry>
           <
key>access-token-issue-time</key>
           <
value>iat</value>
       </
entry>
       <
entry>
           <
key>access-token-expires-in</key>
           <
value>exp</value>
       </
entry>
                <
entry>
           <
key>id-token</key>
           <
value>id_token</value>
       </
entry>
       <
entry>
           <
key>username</key>
           <
value>sub</value> <!-- it could depend on the customers IDP
                             configuration, usually preferred_username -->

       </
entry>        
   </
accessTokenResponseMaps>
</
pluginOAuthConfig>

How to define the OAuth configuration file

The different parameters in this configuration file need to be adapted to the identity provider being used. In this section we will explain the different parameters with a focus in Azure AD.

The first step would be to define the value of the ‘oauthConfigId’ property, it should start with the ‘custom_’ prefix and this value will be an option in the connection dialog (that should be selected by the user).

The following properties should be defined with values provider by the identity provider administrator and are dependant of each environment:

  • clientIdDesktop
  • clientSecretDesktop
  • redirectUrisDesktop
  • authUri
  • tokenUri

The property scopes can be included several times to define the scopes that will be included in the OAuth request.

  • It is recommended to include ‘openid’ and ‘offline_access’ for Azure AD.

The capabilities section of the file defines the behavior of the connector to retrieve the access token, refresh token and user name (see OAuth config file for more details).

  • The OAUTH_CAP_SUPPORTS_GET_USERINFO_FROM_ID_TOKEN capability should be set to true in order to retrieve the user name from the access token instead of using a request to the userInfo endpoint.

The accessTokenResponseMaps section defines:

  • Which attributes from the OAuth response include the access token, refresh token and id token.
  • Which attributes from the access token include the time when the token was issued and its expiration date.
  • Which attribute from the id token contains the user name.
  • This is important because Tableau will use this value to store all the retrieved information for this specific user.

Install custom configuration file

Once the configuration file is created, it should be installed to be used by Tableau connector.

  • In Tableau Desktop, the file should be copied to ‘My Tableau Repository/OAuthConfigs’ or ‘My Tableau Prep Repository/OAuthConfigs’ folder (See External/Custom OAuth Configs on Desktop).
  • In Tableau server the instructions from the following section could be followed:

Authentication flow

Any connector developed with the Tableau SDK with support for OAuth authentication the following authentication path will be followed.

  • The OAuth 2 authorization code grant type will be used.
  • To build both requests (authorize and token), the connector will use the information defined in the following properties:
  • clientIdDesktop
  • clientSecretDesktop
  • redirectUrisDesktop
  • authUri
  • tokenUri
  • scopes
  • capabilities.OAUTH_CAP_REQUIRE_PKCE
  • capabilities.OAUTH_CAP_PKCE_REQUIRES_CODE_CHALLENGE_METHOD
  • capabilities.OAUTH_CAP_FIXED_PORT_IN_CALLBACK_URL
  • capabilities.OAUTH_CAP_SUPPORTS_STATE
  • Once the OAuth response is retrieved, the connector must get the username.
  • If OAUTH_CAP_SUPPORTS_GET_USERINFO_FROM_ID_TOKEN capability is true, the username will be retrieved from the id token.
  • Otherwise, a new request for the user info endpoint will be sent and the username will be retrieved from the response.
  • The value of the ‘userInfoUri property (which is optional and not defined in this example) will be used for this request.
  • In both cases, the value defined for accessTokenResponseMaps.username will be the attribute which should include the user name (in the id_token or in the userInfo response).

Testing OAuth authentication

To test the OAuth authentication with the Denodo JDBC connector:

  • Open the Denodo data source connection dialog.
  • Select ‘OAuth authentication’ in the ‘Authentication’ field.
  • In the Oauth Config Id field, select the value that matches with the value included in the configuration file (which should start by ‘custom_’.
  • Click on the ‘Sign in’ button.

Questions

Ask a question

You must sign in to ask a question. If you do not have an account, you can register here