Publish to Tableau Server: Getting Away From Embedding Credentials

[elsastark]

Hi Community!

Looking to solve a problem we have with using the Publish to Tableau Server tool (amongst others) - I have an idea but not sure if it is the right answer. 

Problem We're Trying to Solve: When using different tools within Alteryx that connect to other applications (Tableau, OneDrive, ServiceNow, etc.) - there is a username and password that typically needs to be embedded.

As we start to scale Alteryx at our organization, we don't want to have different user's passwords embedded for a couple of reasons. This is because:

• Password changes - this happens often enough and causes workflows to fail
• Auditing - Tableau administrators want to be able to understand who published a data source, and they especially don't want it to say User A who developed the workflow when they were not involved
• Permissions - Ensure that if User A publishes a workflow and shares it with User B - there is still some sort of authentication to ensure that we aren't bypassing permissions and licensing models we have established with Tableau Server

Current Idea: I'm thinking the best way to solve this is building a wrapper around the Publish to Tableau Server tool, where we embed one user (svc4alteryx for example). This service account would be responsible for any data sources that are published to Tableau Server. If the Tableau administrators need more information on who published it, we can show them our auditing logs. This would also mean that there would be only one extra Tableau license needed to accomplish this. 

Then, similar to how the Publish to Tableau Server tool authenticates a user, there needs to be some sort of authentication of the run-as user on Gallery. We would need to confirm that run-as user has access to publish a data source to the site and project they specify in the workflow. If they do have the right permissions, then we go ahead with publishing to Tableau Server using our service account. This helps us to not have to embed user credentials and gets us away from someone sharing a workflow with a person who doesn't have the right permissions within Tableau. 

Obviously not ideal to have to manage all this custom logic to help us to use these kinds of tools in our organization, but hoping we can build it in a reusable way where we can apply the majority of the logic to multiple tools and connectors.

If you have another approach or if you think I'm missing an obvious solution, would love your feedback!

[MarqueeCrew]

Hi @elsastark ,

What an interesting thread for consumption!

@NicoleJohnson @grossal @patrick_digan @andrewdatakim @SeanAdams @cgoodman3  @Samanthaj_hughes  for a start.  

Cheers,

Mark

[SeanAdams]

Hey @elsastark 

Another pattern that can help with this solution is to use a password vault - this does require an investment within your firm, but it is actually very useful in the longer term. 

Problem with fixed Identity:

While the idea you posted below (using one identity) does work - the worry that I have with this is that you create both a single point of compromise and also potentially obscure ownership.   

- The compromise issues is similar to when people access a database using pass-through entitlement, where instead of using an explicit username & password for their database - instead they just use the Alteryx Server's service account.    This appears to work well and eliminates password change - but the problem is that ANYONE can create a workflow, publish it to the server, and have access to everyone's data - so you've essentially just eliminated any password security

- The ownership issue is that when we look at our tableau server - if every data-set looks like it was published by user "GenericUser1" then when that data-set goes wrong for some reason, there's no way to figure out who to call.

The Password Vault route:

If you are using a password vault in your firm - this would work differently - you wrap any tool that requires DB credentials in a macro wrapper where you pass in the username & pwd (you need the macro because many of Alteryx's tools don't the ability to dynamically change username & pwd).    Before you call this - you first call your password vault.

In case you are not familiar with password vaults - they are essentially a repository for secrets - and you can store any secret you want.    When you call it you say "I am Sean, and I want the contents of secret number 7" - and the password vault then authenticates to see if you are entitled to this secret and then sends it back to you.

For the better password vaults out there - you would typically integrate them into your firm's password discipline - so that you never need to manually change passwords - the vault contains the latest and coordinates password refreshes with the DB.

I know this is not a simple route - and I apologise for that - the question you are asking is a painful one for any company of a reasonable size with a decent password change policy - hopefully soon Alteryx will directly support pwd vault integration and this will become a lot easier.

Good luck - and post any updates as you find other ideas (either practical or a little crazy)

Sean

[elsastark]

@SeanAdams - Great idea! We do have a password vault in our organization, that we use for our Alteryx Server deployments. I'll work with that team to see what's possible. And if that doesn't work out, the nice thing is that our admin reports for Alteryx are actually stored on Tableau Server under our general COE site (we have Tableau and Alteryx within the same COE) so if we do have to go with the generic user route we at least have a general place people could go to see who actually published a data source that was published through Alteryx in the same place they would go to see any other audit reports we have for Tableau. Still not ideal as you outlined above, but we at least have a way to answer the question. 

And to your point on pass-through entitlement, that is where we would need to make sure we still have some sort of authorization that the user can in fact publish where they are specifying, not just the service account we set up. Basically, use the same API calls Alteryx uses in the tool simply to check if that person can in fact publish there and once that is confirmed, then we actually publish. We would use the __cloud:UserId logic to get the run-as user to confirm that person can actually publish to Tableau Server. Still not a clean, simple solution but fits our requirements.