Although flows that are bundled in a solution can call each other natively, flows that have a SharePoint manual trigger are not allowed to be included in a Power Automate solution. That means I have to create my flow with the SharePoint trigger outside the solution, and then call the child flow (inside the solution) using an HTTP call. My question is: what's the best way to secure that call?
I've tried using the API Management service in Azure to wrap the URL, but I'm struggling because all the examples are for calling Logic Apps and are about 5 degrees away from what I'm trying to do, which is to simply add security to my HTTP call. Can anyone provide any guidance? (Am I missing something really simple?)
Solved! Go to Solution.
Thanks. At first I was trying to use API management but then realized all I'm doing is obfuscating the call, but that doesn't really secure things from the receiving end. I didn't really want logic inside my flow having to check any values, because by then, I've used up one of my flow runs. I like the idea of passing in a token into the trigger, and then having a trigger condition. That way, if someone attempted some sort of denial of service attack, it's Microsoft's problem and not mine, since it wouldn't count toward my flow runs and my code wouldn't execute.
Does securing the inputs and outputs do anything more than hide those inputs and outputs from the UI? I'm not so worried about people internally having access to the right stuff, but more hackers getting a hold of the flow's HTTP trigger URL and firing it.
Check out the on demand sessions that are available now!
ISV Studio is designed to become the go-to Power Platform destination for ISV’s to monitor & manage published applications.
See the latest Power Automate innovations, updates, and demos from the Microsoft Business Applications Launch Event.