Advent of Code is back! Unwrap daily challenges to sharpen your Alteryx skills and earn badges along the way! Learn more now.
Free Trial

Alteryx Server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.

Connecting to Row Level Security Data Sources

elsastark
10 - Fireball

Hi Community!

 

We have a question about the best practices for connecting to data sources that have row-level security. Usually, this security is being inherited from Active Directory groups that have been set up. 

 

An example of this is with our EMEA processes. We may want a leader from the UK to run the workflow and get results and data for their country, whereas a leader in Dubai should only see their piece, and then our regional leaders would be able to see all of the EMEA regions - ideally all running the same workflow. 

 

Currently, we have data connections set up for these data sources but probably need to explore other ways to connect to these data sources so that the run-as user is taken into consideration when pulling in the data. We also want to make sure we have:

  • A clean way for users to connect to the data source when developing workflows in Designer (not embedding it themselves)
  • The administration side of it is fairly simple - nothing where we have to update individual workers each time a connection needs to be added or changed.

 

Let me know if you have been able to accomplish something like this before, and how you went about it. Appreciate the help!

5 REPLIES 5
MarqueeCrew
20 - Arcturus
20 - Arcturus

Referring you to a Master:  @SeanAdams 

Alteryx ACE & Top Community Contributor

Chaos reigns within. Repent, reflect and restart. Order shall return.
Please Subscribe to my youTube channel.
SeanAdams
17 - Castor
17 - Castor

Thank you for cross-tagging this @MarqueeCrew !

 

Hey @elsastark 

First thing to confirm - you're not missing something easy and obvious - this is a challenging request in Alteryx currently.

 

What other applications do is called "kerberos passthrough" or "implicit kerberos" - where the gallery would know that user SeanAdams is logged in; and would pass this information on to the underlying DB which would authenticate as SeanAdams.     This has some pros and cons though - namely:

  • cons: If you are doing enterprise level reporting, you want everyone to get the same summary details (e.g. the company sold X widgets, irrespective of who the person is that's asking the question)
  • pros: as you say - there are cases where you only want people to be able to see the details that they are entitled to.

Given that Alteryx does not provide for Kerberos passthrough - you have a few options:

  • You can use the Run As functionality - I've not used this myself, but I believe it's possible to configure the server to allow users to specify their credentials at the time of running the canvas.    If you do this - then you'll need to make sure that all your database connections are set up as "Trusted" connections - i.e. don't specify a username and pwd, just use the requester's credentials.    On MS SQL server, this is just the text "trusted=yes" in the ODCB connection string (or something similar).     Alteryx Analytics 10.5 Introduces New Workflow Exe... - Alteryx Community
  • Create something like kerberos passthrough.   
    • Make this an analytical app where you ask for the user's name & pwd - and them pass them through into the DB connection.     This may not be allowed by your compliance folk because of the possibility of you storing a copy of the user's username & pwd somewhere.
  • You can filter the data by the user name.   
    • Similar to the post below (Solved: Gallery authentication pass thru to workflow - Alteryx Community) - you can probably use an internal variable like "__cloud:UserID" to find out the internal Alteryx User ID.   You'd then need to query the server's Mongo DB to figure out the user name.   This can get very complex very quickly.
      • Once you have their username; you can then filter the results using logic in your Alteryx canvas, or in your DB (for example, you can pass the username in the select query like "select * from sales where salesPerson =  'SeanAdams'"
      • or you can do this on the Alteryx side if you have the row-level security logic handy and can implement this in Alteryx
    • or you can ask them just for their user-name on the gallery as a single box, and do the same as above (filter inDB or filter in Alteryx)
  • Run on desktop:
    • If they have alteryx installed on their desktop - you can package this as an application and they just need to double-click on it (desktop IS able to pass identity through to the DB, so if your row-level security is set up on DB level, then this will work seamlessly)

 

So - sadly there's no easy option - I think that "Run this canvas always with Kerberos Passthrough" would be a very good server idea - and it's worth you logging this under Server Ideas (https://community.alteryx.com/t5/Alteryx-Server-Ideas/idb-p/server-ideas) and tagging Mark and I on that, and we'll support your suggestion and add to that discussion.

 

Good luck @elsastark  - once you have a solution that works, let us know how it goes on this thread so that other folk can learn from your journey?

 

Have a good week

Sean

 

 

 

 

 

Here's another post that deals with the same topic:

Solved: Gallery authentication pass thru to workflow - Alteryx Community

elsastark
10 - Fireball

Thanks @SeanAdams for all the info, very helpful to know I'm not missing something obvious!

 

I posted the idea and will keep you updated on what I figure out in the coming months to help support processes like this. 

 

https://community.alteryx.com/t5/Alteryx-Server-Ideas/Run-Canvas-With-Kerberos-Passthrough/idi-p/928... 

bcawells
5 - Atom

@elsastark wondered if you ever successfully implemented any of the above suggestions by @SeanAdams ?

elsastark
10 - Fireball

@bcawells No - but we are currently looking into using DCM as a way to implement row-level security. We will essentially share the connection information without the credentials then each user will configure their own credentials to attach to the shared credential.