This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
The 2022.1.1.30569 Patch/Minor release has been removed from the Download Portal due to a missing signature in some of the included files. This causes the files to not be recognized as valid files provided by Alteryx and might trigger warning messages by some 3rd party programs.
If you installed the 2022.1.1.30569 release, we recommend that you reinstall the patch.
We have started to get into more and more complex logic where one of our challenges is determining who is running a workflow not just afterward, but while the workflow is being run.
We have some processes (usually for security reasons) where we want to understand who is running the workflow and use that to determine what happens with the workflow. In our ideal world, it would be something we can reference easily like the Workflow Constants so it would be something like %Engine.RunAsUser%.
An example of this is we want to determine if that person has access to write to our data lake through our data lake APIs - but to do that we need to pass in the person's employee ID. We don't want to ask the employee for that ID through Interface tools because that isn't secure (Employee A could put Employee B's ID).
I have a potential solution of using the _cloud:UserId value to get someone's User ID then joining that up with the users table within Mongo but wanted to see if anyone has found a simpler solution.
This might not be the most elegant approach but worked for one of my clients because of its simplicity.
The idea is to enable access control using windows authentication. You would need to encapsulate the logic for the API write calls within a macro and place this within a shared drive. Make sure the reference within the workflow to the macro is at this shared drive path.
You can then control which user can access this drive location using existing controls. Any user without this access will be shown a error as the macro would not be accessible. One of the reasons we went for this approach was to prevent additional control layers being built.
If the write is happening through data connections you can control who can access them using the gallery functionality.
@JagdeeshN - This would control who can access a macro or a data connection, but I'm not sure if it would work for us because we need to authenticate if that exact user can do certain things.
With the data lake example, Employee A and Employee B may both be able to write the data fabric (which I think in your example would mean they would both have access to the macro in the shared drive path). But Employee A can't write to where Employee B can. So I need to have logic in my workflow that knows who is running the workflow on Gallery so it can then ask, "Employee A is running this Alteryx workflow on Gallery and wants to write to Package ABC in the data fabric. Can they?"
We also deal with this with regional processes. Trying to build workflows that understand who is running it and therefore pulls data or writes to a different place (UK vs. Italy vs. France).
Let me know if the solution you mentioned could do something like that, appreciate the help!
Probably best to explain with a scenario - this is just one example of why we are needing this functionality. Let's say I have a workflow called "Workflow ABC" that is published on Gallery. Within Workflow ABC, we need to capture who is running the workflow because they are publishing a Tableau data source to Tableau Server (using APIs). For example,
When Person A runs Workflow ABC, the workflow will check that Person A has access to publish to Tableau Server.
When Person B runs Workflow ABC, the workflow will check that Person B has access to publish to Tableau Server.
So, within Workflow ABC, we need to have a field of some sort that identifies who is running the workflow.
Using the AS_Queue table, while Workflow ABC is running, I can query Mongo and find the row(s) where Workflow ABC is running. But if Workflow ABC is running by two different users (Person A and Person B) at the same time, then I won't have a way to say which user it is because my query would return two rows.
Do you have any ideas on how I could differentiate the two within Workflow ABC while it's running?
I've managed API access by storing the credentials in SQL and then leveraged windows authentication based on the run-as user. If they can query the desired data from SQL, then the API call can be properly composed. You could store additional data elements that could define the scope of the API calls based on the user in question.
It adds a layer of complexity to your workflow, but it does work nicely, and allows for dynamic workflow behavior based on the run-as user.
@carlosteixeira Assuming the user is the Run As, what technique did you use to figure out the user? The only idea we have so far is to run a cmd with "Who Am I" basically asking the Windows OS (who is owner of this process). Is there a better way?