Sharing Data Connections with User Groups | Alteryx 21.2

[SophiaF]

Sharing Data Connections with User Groups | Alteryx 21.2

 
Data Connections allow a Curator (Gallery Admin) to create, maintain, and permission database connections via the Gallery. These connections can then be used when building Designer workflows.
 
With the 21.2 release, Administrators now have the ability to share Data Connections with Custom Groups and Active Directory groups.
 

Permission Changes

Additionally, starting in Version 21.1, we have increased security around workflow execution with workflows that are shared on the Gallery and use a Data Connection. Moving forward, the Data Connection must be shared all users who run or schedule the workflow on the Gallery. This is a change from previous versions, where the only requirement is that the owner of the workflow needed to have the Data Connection shared with them. This ensures that only the users who should have access to the Data Connection can run the workflow.
 
Users will get the error "Unable to Translate Alias" if they attempt to run a workflow that uses a Data Connection that has not been shared with them.
 
 
 

FAQs

I only see the option to share to a Custom Group. How do I share a connection with an Active Directory group?

Your Gallery Admin will need to create a Custom Group and add the Active Directory group into that Custom Group. Then, you can share the data connection with the Custom Group, and all users in that Active Directory group will have access to the data connection.


As an Artisan, how can I make sure that my workflow can be run by my colleagues?

You will need to notify your Gallery Admin of who you plan on sharing this workflow with once it is published on the Gallery. Generally, this will either be by placing it in a Collection, or by uploading to a shared Private Studio. The users in your Collection or the users in your Private Studio will need to have that Data Connection shared with them.


What if my workflow is shared in the Public section of my Private Gallery?

All users who run the workflow will need to have the Data Connection shared with them.


Does this apply only to newly created workflows published after 21.1?

No, this change will apply to all workflows on the Server once you upgrade to 21.1+. If you have workflows that use Data  Connections, your Administrator should start working with the users that have access to these connections in order to start sharing the data connection(s) to the users that need to run these workflows.


Would any of those users with a Designer license then be able to use that Data Connection in Designer?

Yes - If the data connection is shared, that user has all rights to use that data connection. If they have a Designer license, they can create new workflows with that connection, and if they are an Artisan they could publish these workflows. The sharing of these connections is all or nothing.


What if the workflow is being run as a different user, via a "Run As" user or specific Workflow Credentials? Does the connection need to be shared with that user?

Only users that are performing the following actions need to have the data connection shared with them:

1. Running the workflow from the Gallery (clicking Run) 
2. Creating a schedule using that workflow

Both of the above are performed by the user who is logged into the Gallery. Any type of Run As user does not need access.
 

Additional Resources

 

• Data Connections | Alteryx Help

[mercra]

We had an interesting problem when we upgraded to 2021.2 which changed our data connection auth behavior.   The issue we had was with existing workflows (workflows uploaded to gallery BEFORE we upgraded)... We're not certain, but it appears that they existing workflows retain their old security behavior.  They appear to use their owner for auth and not the user running the job...   We suspect this because we didn't auth running users and we didn't get a any users complaining.  In addition, when we removed the owner from the data connection, nobody could run the workflow.

The tricky part was adding the owner back in did NOT fix the problem.  I'm guessing under the covers the security was linked to the specific record in mongo and not just the owners name/id... Adding that owner back in did not fix things because the original row that the workflow was linked to was gone...  By then there was no turning back and the user had to reupload their workflow making the workflow flip to the new security model.

The above is just speculation as we haven't gotten any answer back from Alteryx, but it fits our experience.  We wanted to post this in case anyone else runs into this problem.  This page helped us 'understand' the different security models, just didn't call out what happens to existing workflows upon upgrade.

[Franz]

Interesting, and good to know, although I hope that the WF 'owner' user should be irrelevant once the appropriate identities (a user, Custom.Grp - AD Grp. memberships) are added to the Data Connection; I hope I'm right on this.

[alberto_herni]

Hi @SophiaF,

Thanks for the post as it has been critical to understand this new DB connection permissions rules after upgrading our Alteryx Server.

In our case we are running workflows with DB connections through the Alteryx Subscription API, as you may know these executions are not done by an specific user, instead they appear in the server without assigned user. We are getting the 'Unable to Translate Alias' error for these executions, I have tried to share the connection with the 'run as' account we are using, but this is not working and we continue getting the error.

What should we do in order to continue executing these workflows from the API?

Thanks in advance.

Regards,

Alberto HM

[AudieCruz]

Hello @SophiaF : 

We recently updated to 2022, ,from 2019, which is a big jump and we're now getting impacted by this after building a business process behind the old rules. 

It seems odd to implement this change as a measure to increase security, when it seem to promote the opposite. 

For example, under the prior rules we: 

* could create a workflow using a DB connection

* control what of that DB connection is used  

* share the workflow via gallery, and allow an end user to only partake to the limited access provided by the artisan from the DB

* if the end user decides to download the workflow, they wouldn't be able to run it because the user doesn't have access to the overall DB. Which in my opinion is better for security. 

With the new rules: 

* I would have to engage with the server admin if I want to share a workflow via gallery with a DB connection to provide access a la carte. 

* The user would have full access to the DB, when in turn that is not the intent of the share. Just access to what the artisan provides. 

This change seems to expose our institution to provide more access, when the prior rules gave us more control of who has access to the data. 

[mercra]

@AudieCruz  I agree that this seems to open things up considerably.  Having access to a data connection as an artisan allows the artisan to fully query the data within the data connection well beyond the original artisans goal.

You explain this very well in your post.

If you compare this to custom software development with a client application and a database, we give a client application access to the database via a service account. We don't give the users access to the database at all, we give the users access to the client.   The users therefore can't do anything more to the data than the client app allows.

The introduction of DCM hasn't helped on this front, but we're told that it could/should with the mid 2023 release.   Finally there will be 'sharing' without the password.  For our company every user is given their own access to the database and controlled tightly.   If a developer can create an workflow and define the data connections it uses, then share the workflow with others and the data connections without credentials then the user can run the workflow, but must provide their own login/password for each data connection.  If the user doesn't have their own login/password to the database, they can't run the workflow.    We're waiting for the midyear release to see if the design works better for us.  (We're also hoping they fix the ownership problem.  If user x owns 10 workflows and 3 DCM connections and leaves the company, can we easily pivot the workflows and dcms to another user... if not, then we're back to this being unusable)

For those that use service accounts for database access, the DCM mid 2023 enhancements might help here too.  Hopefully sharing DCM connections allows for 'use for development' vs. 'use for running workflow' control (or something similar).  We're told security and the 'enterprise' concepts will be much better with this release (though we've heard this before on other topics and things fell a little short - like the cool new v3 api that currently only works for curators!).    I highly encourage you to reach out to your account manager and setup a meeting with product development to ensure what they delivery mid 2023 fits your needs.   

Alteryx, do you plan on improving gallery connections with more sophisticated permissions - or is DCM the future?  If DCM, how easy will moving a workflow from gallery data connections to DCM connections? 

If anyone knows a way to fix this with current version please post a response.

[Franz]

Hi team, 

I believe that the (configurable) DCM is a step in the right direction. So far it's been working almost perfect for us (ver. 2022.1.1.408...). The exception is the sharing via AD groups (user roles). Once that is fixed, the problem you have with sharing the connection should be resolved. Until then one has to work with the 'local' Custom Groups which is not suitable for enterprise environments (but will do the job for now..). You don't need to 'interact' with the Alteryx Admin to configure who is able to share the connection, in  most cases...(other than the 'drivers/connectors' installation, but that needs to be done once anyway). The connection is just a combination of a data source & a credentials. So whether you use a service account on the connection or individual users' credentials every such connection will provide access to the applicable schema (in regular database terminology). That's of course in the case of username/password authentication method, where the end users normally don't have the physical database host details anyway. Other storage technologies such as the cloud (Azure, AWS, Google) don't work with this, and for a good reason, username & password is less secure. So your admin should welcome that. I also hear that the OKTA authentication will be introduced...

[mercra]

The DCM might work for some customers as is.   We can't use it BECAUSE users can circumvent our user access rules.   User A can write a workflow that uses Data X and then share it with user B who now has access to Data X without any controls... Not allowed at our place so thats a show stopper...  I agree that at least user B can't do anything beyond what the workflow does so user B doesn't have FULL access to the database like the gallery data connection allows.  At this point its kind of which solution is least bad...  

As I write this I wonder if there is a way to use DCM but to audit nightly to see if anyone that isn't authorized for that data is identified.  Leave the users to manage the data, but quickly find violations.... hmmm.... 

DCM doesn't allow for custom groups that include AD group members?