Capturing who is running a workflow within the workflow being ran on Gallery

[elsastark]

Hello Community!

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.  

[JagdeeshN]

Hi @elsastark ,

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. 

Best,

Jagdeesh

[elsastark]

@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!

[carlosteixeira]

Hello @elsastark 

I think you could use a part of this flow that I created to monitor the jobs that are running with a time greater than 1 hour, regardless of whether it was run manually or scheduled.

https://community.alteryx.com/t5/Engine-Works/How-to-Cancel-Manual-Jobs-in-Alteryx-Server/ba-p/90192...

In the third part, I can identify who is the user who is running this job.

Maybe with this first information, you can use some auxiliary table with this user's access information to your database doing a join or something.

Would this help start the development of your workflow?

Thanks

[elsastark]

Hi @carlosteixeira - thanks for this! I will look at it closer to see if I can use some of your logic for this - I'll keep you posted!

[elsastark]

Hi @carlosteixeira - was attempting to solve this with your logic. Is there a way to identify the specific workflow you're running? 

I have it filtering on status and application name. I packaged it into a macro so it is capturing the app name from the parent workflow using Engine.WorkflowFileName

One way I don't see this working is when a workflow is running in parallel - is there a better way to identify the workflow?

[carlosteixeira]

Hi @elsastark 

Q: was attempting to solve this with your logic. Is there a way to identify the specific workflow you're running? 

A: Maybe if you include some interface tools to change a filter and get a direct status of the specific workflow. I don't know if I understand your question

Q: One way I don't see this working is when a workflow is running in parallel - is there a better way to identify the workflow?

A: I don't think so unless you go to the gallery's admin page and see how the workflows are running, but I don't think that's exactly what you want.

Give some more details about what you wanna do and I can think about a new strategy for you!

Thanks

[elsastark]

Hi @carlosteixeira 

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. 

Workflow	User	Status
Workflow ABC	Person A	Running
Workflow ABC	Person B	Running

Do you have any ideas on how I could differentiate the two within Workflow ABC while it's running?

[raychase]

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.

[mercra]

@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?