Security - How can I secure the HTTP - Request trigger ?

(0) Share

Report

Posted on by yoshihirok

1,724

I want to restrict my HTTP - Request triggers with IP address, Users, Organization.

for secure my flows.

At creating a flow at SharePoint with a template 'Complete a custom action for the selected file',

The flow start with 'HTTP - Request' trigger.

And the 'HTTP - Request' trigger can use anyone who know trigger's HTTP POST URL.

No restriction can use the flow like IP address, User authentication, Organization.

I want to create flow menus in SharePoint List, SharePoint Documents with security.

How can I secure ?

Regards,

Yoshihiro Kawabata

Categories:

General topics

I have the same question (0)

All responses (3)

Answers (1)

Verified answer

v-micsh-msft on at

Like (1)

Report

Hi @yoshihirok,

I don't think there is a way to restrict the HTTP-Request (things like IP address, Users, Organization.) whe nworking with Microsoft Flow.

Please consider submit this as an idea under Microsoft Flow idea forum:

https://powerusers.microsoft.com/t5/Flow-Ideas/idb-p/FlowIdeas

Regards,

Michael

Was this reply helpful? Yes No
yoshihirok 1,724 on at

Like (0)

Report

Hi @v-micsh-msft,

Thank you for your reply.
I post a idea 'Security - restrict HTTP - Request trigger by IP address, tenant, group, users '.

Regards,
Yoshihiro Kawabata

Was this reply helpful? Yes No
ryanshane 4 on at

Like (1)

Report
This is what i did:
One of my request parameters to include in the POST is "requestToken"
In the logic app verify the request token
You could just use a hard coded GUID as some form of security, or inside your flow you could try to calculate something more complex based on time and date, forming a token that is valid only for a period of time. You could do this with an azure function or third party token verification service. The caller would need to perform the same calculation to create a valid token. This might be sufficient depending on what the flow does. This is similar to some Single Sign-On implementations to authenticate with an public website from inside a corporate network - where a token is generated (based on private key, date, and username) and included in the URL on first hitting the site. The website can then assume the user is in its list of known users since the username was incorporated in the token.

Was this reply helpful? Yes No