Enable OAuth authentication for our connector if we do not know the OAuth provider in advance?

[carlossc]

About You: Name: Carlos Santos Canelles Company: Denodo Technologies

Your question:

We are using this SDK to develop a connector for Denodo. Can we enable OAuth authentication for our connector if we do not know the OAuth provider in advance?

Our Scenario

Think of Denodo as a relational database. Denodo supports OAuth authentication. That is, an application can obtain an OAuth access token and use it to connect to Denodo with our JDBC driver; the application only has to put the token in a driver property.

The administrators of Denodo configure Denodo to use the OAuth provider their company uses; they do not need to use a specific provider. Denodo is not a SaaS service, the customers install it on their computers/cloud instances; we do not manage the Denodo servers.

More Details About the Question

In our scenario, we do not know any details about the OAuth provider. This is something each customer sets up differently in their Denodo server. I.e. we do not know the authorization endpoint URL, the token endpoint, client id, client secret... so we cannot include it in the oauthConfig.xml.

In the documentation (OAuth Authentication Support), there is a table that says that these parameters are mandatory:

• authUri: authorization endpoint
• tokenUri: token endpoint

but we do not know this information. However, the documentation also references the property OAUTH_CAP_SUPPORTS_CUSTOM_DOMAIN: Whether your OAuth provider supports custom domain. i.e. OAuth endpoint host is not fixed..

From the documentation, it looks like when I load the connector into Tableau server, I can customize some of the OAuth parameters. The documentation has this example:

tsm configuration set -k oauth.config.clients -v "[{\"oauth.config.id\":\"[your_dbclass]\", \"oauth.config.client_id\":\"[your_client_id]\", \"oauth.config.client_secret\":\"[your_client_secret]\", \"oauth.config.redirect_uri\":\"[your_redirect_url]\"}]" --force-keys

This example customizes the client id, client secret and the redirect URL.

Question, when I execute tsm, can I add there any of the parameters of the oauthConfig.xml?

More background information

Tableau already has a connector for Denodo, which uses the PostgreSQL ODBC driver to connect to Denodo. This connector was added to Tableau 6 years ago. We are developing a new connector that uses the JDBC driver of Denodo, which performs better than the PostgreSQL ODBC driver. In addition, we will have more control of the SQL dialect the connector uses.

We would like to add OAuth authentication to the new connector because several mutual customers told us they would like to use OAuth authentication when connecting to Denodo from Tableau.

[wangxinlei]

Hi Carlos, Thanks for your question and I'm glad to answer those. So for our existing OAuth support we do not support overriding other fields of OAuthConfig.xml file in Server, the only customized fields are ClientId, ClientSecret and Redirect_Uri. All the other fields such as authUri, tokenUri and other OAuth capabilities must be known before your server starts up, and what you recommend that override the whole oauthConfig.xml file feels like the customer just need to re-write the Denodo plugin connector's OAuthConfig file.

1. If you are only caring about On-Prem install of Tableau Server(no Tableau Online), you probably can offer customer guidelines on how to write their own Denodo Plugin Connector in their server and probably provide a template for them. But this approach will not work for Tableau Online.
2. We are currently investigating to support Multiple Idp per plugin connector, which means for your Denodo plugin Connector you can config multiple OAuthConfig.xml file which correspond to multiple different Idps such as GSuite, Azure, AWS, OKta, etc. In this way the user can choose which Idp they wanna use and invoke OAuth flow with that. This model will work for both Tableau On-Prem Server and Tableau Online and does not need user to write any OAuthConfig file. But the limitation of this is that we must know ahead what are the possible OAuth Idp customer gonna use and develop the correct OAuthConfig file for it. It may not be a big issue since we can always upgrading the connector to include more Idps if necessary. Does any of these approaches sound reasonable to you?

[carlossc]

Hi, Thank you for replying so quickly.

In general our customers expect to be able to use whatever Identity Provider they want. I am thinking of several government bodies that are customers of Denodo and that use an in-house-developed OAuth providers they consider more secure.

I think for Tableau On-Prem Server, the best option would be that with the tsm configuration set -k oauth.config.clients..., the administrators of Tableau could customize all the OAuth config attributes of the oAuthConfig.xml, not just ClientId, ClientSecret and Redirect_Uri. This would allow the administrators to use the Identity Provider of their choice instead of being forced to specific ones.

Re comment 1, most of our customers use Tableau Desktop and Server (not Tableau Online). This option is not ideal because customers have to repackage the connector and sign it to be able to load it in Tableau. They will probably have to create a self-signed certificate to do it and in that case, add the certificate to the JRE truststore. That said, since several customer expressed interest on this, we will probably document how to do this. It is a bit cumbersome but it will do.

Re comment 2, in the medium term, I like this idea and I guess it fits well with the model of Tableau Online. However, for On-Prem, I think the solution would be better if users were not constrained to specific IdPs.

[wangxinlei]

OK so currently we do not support bring-your-own the whole oauthConfig file, since our model is the developer should know what Idp they support beforehand and they can setup some security enhancement such as setup the validation rule for instanceUrl. If we allow to BYO whole oauthConfig, we'll probably need to change other fils as well such as in connectionFields.xml there's a field called instanceUrl and should only be shown if your OAuth config supports that, and it has a UI validationRule that is setup in that connectionFields.xml file. Besides, our registration for a pluginConnector will need to register all files in that TACO file at once, we do not currently support override one of the files(oauthConfig.xml) in a later phase. How we support override CI/CS is we are passing them around for every request, maybe we can pass the whole file content around to satisfy this need but we'll need to evaluate that. I guess maybe in the future we can overcome these and finally support fully customized oauthConfig but we do not have such feature in our backlog and we do not know how many customers need/want this. @sidwray I'll loop in Sid, our PM. Also @rosswbrown if he has other ideas.

[sidwray]

Thanks Carlos, supporting customer provided OAuth Clients is on our roadmap. Setting as an enhancement request.

[leniartek]

Hello @sidwray, this feature is also top priority for Starburst Data connector.

[carlossc]

@sidwray Do you have an approximate time frame to add this to the SDK? Thank you.

[sidwray]

I can't comment on a date specifically, but this is in progress at the moment. Can you share any driver documentation with me that describes how the driver would accept auth tokens? Because of the nature of where the driver can be installed (on a Tableau Server machine, or in our Tableau Cloud environment), we have a native OAuth Service that is configurable by a customer. Tableau will run the browser-based OAuth 2.0 flow and manage interaction with the IDP, and then expect to pass auth tokens to the driver.

[carlossc]

The Denodo JDBC driver expects to receive the OAuth token in the connection URL. For example: jdbc:denodo://denodo_server.acme.com/?useOAuth2=true&accessToken=aksaklsdlksda

You can also pass useOAuth2=true and accessToken as a driver property instead of in the connection URL.

Documentation about this.

[carlossc]

Is this feature available in Tableau 2023.1 and the latest version of the SDK?

[sidwray]

Hey Carlos, We just released this update along with 23.1 late last week. I was going to send you a note separately. Feel free to review the docs and let me know if you have any questions or feedback. Thanks! https://tableau.github.io/connector-plugin-sdk/docs/oauth

[omeuid]

Hi,

I was performing some tests after reading the documentation article that you share and I have some questions that maybe someone can answer.

Is there a way to develop a connector which follows the following behavior?

• For Tableau 23.1 (and future ones), the connector will provide several OAuth providers with several OAuthConfig.xml files.
• In previous versions of Tableau, the connector will use a specific OauthConfig.xml file.

In my tests, any connector which takes advantage of the new OAuth capabilities is not able to work as I expect in previous versions of Tableau.

Is there a way to accomplish what I intend to?

Regards.

[sidwray]

This functionality is not backwards compatible. Both Tableau and the Connector will need to be updated.