As Power Platform Admins, a common focus area is the control of integrations. The HTTP and HTTP With Entra Id connectors tend to be a primary source of concern since they allow Makers to make HTTP calls to a vast range of endpoints from Cloud Flows. Even though it is possible to restrict these connectors with Power Platform DLP Policies, some key capabilities are still missing. One in particular: VISIBILITY! We need a way to monitor the HTTP endpoints that the flows send requests to. And it is even better if we can detect hard-coded secrets at the same time. Let’s take a look at how we can do this… And how I can help with a reusable solution for it!

• Capabilities already available to monitor HTTP Endpoints
• The Endpoint Collector Solution
• Limitations

The capabilities already available to monitor HTTP Endpoints

Let’s briefly review what is available today to govern the HTTP and HTTP With Entra Id connectors:

• DLP Policies: they allow to enable or block specific connectors in an environment. Admin can enable or block both the HTTP and HTTP With Entra Id connectors via DLP Policies.
• Endpoint filtering on DLP Policies: a few years ago Microsoft released the capability to whitelist or blacklist HTTP endpoints. It then became possible to enable them only for a list of endpoints. The caveat? This feature is still in preview today, I suppose because it is still possible to bypass these rules. If we set the Uri parameters with dynamic values (variable, compose output, etc…), then these rules do not apply 🤯.
  
• CoE Starter Kit: The CoE Starter Kit gathers inventory data across the tenant. Admins can use this data to identify the flows using the HTTP and HTTP With Entra ID connectors. The Sync Flow “Flow Action Details” gathers data about all the actions configured for each cloud flow, but it does not store the configured endpoints. It also indicates whether the flow contains some “plain text password”. However, it only checks for the word “password” inside the flow definition. It does not check whether the password is hardcoded or dynamically obtained (with Azure Key Vault for example), nor does it check for client secrets.

Let’s then briefly summarize what we are missing:

• The list of the endpoints configured in the HTTP and HTTP With Entra Id connectors in each Flow
• The detection of whether these connectors are configured with hard-coded secrets

The Endpoint Collector Solution

Let’s have a look at the solution I propose to monitor HTTP Endpoints in cloud flows. You can download it from my GitHub repository below.

Let’s start by admitting that it is far from being perfect. It is only but an attempt to address the above gaps. There is a lot to improve (see limitations), and I welcome any help from the community to further improve it. I also did not come up with this from scratch. It is in big part inspired by the existing CoE Kit Flows (Flow Action Details) as well as by some work done by my fellow friends Marek Buban and Lukas Kormuth.

Solution Overview

The Endpoint Collector solution is basically an extension of the CoE Kit, like other solutions that I have shared before such as the Environment Settings Enforcer and the Ownership Toolbox. It is mainly composed of a Table, a Cloud Flow, a Model Driven App and a Power BI Template.

The Table: HTTP Endpoint

The table stores the endpoints configured in the HTTP and HTTP With Entra Id connectors. The main columns include:

• Uri: the endpoint configured for the connector (For technical reasons, the character <‘> is replaced by <“>)
• Connector: whether it is the HTTP or HTTP With Entra Id connector
• Method: the method configured (GET, POST etc.)
• Host: the endpoint Host. A Low-Code plugin is used upon row creation to check the Uri with a Regular Expression to identify the Host. When the Uri is configured with a dynamic value, the host cannot always be populated.
• Flow: the Flow from the CoE Kit inventory where the connector is used
• Is Uri Dynamic: whether dynamic values are used to configure the Uri
• Is HTTP Only: whether the HTTP protocol is used (as opposed to HTTPS)
• Is Secret Static: It indicates whether a secret or password is used without using a dynamic value. If this is the case, it means that it is very likely hard-coded inside the flow. However, even if it does not show as being static, it could still be hard-coded in the flow via a compose action or variable. This is how this column is set:
  • If the endpoint is used with the HTTP connector and the Authentication method is OAuth, Client Certificate or Basic, it will be set to True if the Password or Secret action parameter does not contain any dynamic value.
  • If there is no Authentication or if the endpoint is used with the HTTP With Entra Id connector, it will be set to true if:
    • The word “client_secret” or “password” is present in the body, AND…
    • It does not contain any dynamic value.

The Cloud Flow: Collect Flow HTTP Endpoints

The Flow reuses the principle of the CoE Kit Flow “Flow Action Details” to browse through the relevant flows from the tenant and maintain the HTTP Endpoint table.

The original “Flow Action Details” flow from the CoE Kit goes through every action of every cloud flow. For large tenant, this can be pretty heavy and can result in very long flow runs, consuming many API Calls. Instead, this Flow only browses through the Flows using these two connectors. It also only looks at the actions related to these connectors. This significantly reduces the scope of the Flow.

Overview

It is pretty straight forward from a structure point of view:

1. Scope get all Current Endpoints: It starts by browsing through all the flows in scope to store the detected endpoints in a variable. The Environment Variable “Endpoint Full Inventory” defines whether all flows should be looked at or only the ones modified in the last week. This is where the logic is to detect the endpoint and other table columns described above.
2. Scope get all Stored Endpoints: It then checks the endpoints that were already stored in the Table
3. Scope mark as deleted: it checks if any stored endpoints should be removed, in which case it marks them as removed as opposed to actually delete them, for history sake.
   • If some flows were deleted since the last run, it will mark the related stored endpoints as removed
   • If a flow is still in the tenant but no longer connecting to an endpoint, it will mark it as removed
4. Scope create new endpoints: it creates any missing endpoints from the table
5. Scope update EndpointFullInventory to no: for the first run, the Environment Variable “Endpoint Full Inventory” is set to Yes (see first bullet point). At the end of the run it will be set to No to only look at the last week updates. The flow itself is set to run every week.
6. Scope if Error: In case of a failure, an email is sent to the address configured in the Environment Variable “Endpoint Email To”

Key Flow Logic

The first scope is where most of the logic is implemented. If you are not interested in the details, you can skip right to the next section presenting the Model Driven App. Otherwise, stay there!

Getting the Flow Definition

To get the definition of a flow and how it is configured, we can use the “Get flow as Admin” action from the “Power Automate Management” connector:

The output provides a lot of information including all the actions of the flow and how they are configured. The Actions property from the output is not an array of objects. Instead, it is an object itself, of which each property is another object representing an action, a scope, a condition etc. These properties are called by the name of the actions. For example, this is the “actions” object of the definition of a simple flow.

If there is a condition, a scope, or a loop, it will be the parent of the underlying individual actions. Therefore there could be many parent-child levels within the actions object.

Let’s now look at an example of an action object for the HTTP and the HTTP With Entra Id connectors:

The good news is that most of the information we need is there: Uri, Method, etc. The bad news is that it is not so easy to extract and manipulate. Indeed, the fact that it is not an array, that the actions are designated by their name defined in the flow, and that there can be multiple parent-child levels makes it pretty hard to navigate and extract the information we need using Json. We could use some string manipulation expressions and play with split() and replace() to get what we need though it can become complex and hard to read pretty quickly.

Extracting the relevant information from the HTTP and HTTP With Entra Id actions

We need to a way to easily:

• Identify the actions of the two HTTP connectors
• Extract the properties we are interested in:
  • For the HTTP connector, it is the “inputs” property
  • For the HTTP with Entra Id connector , it is the “parameters” property

This is where the XML function comes into play. This function allows to convert a Json object into XML. The interest there is that it is then possible to use the XPath function to easily extract the information we need. Since the structure of the HTTP and HTTP With Entra Id actions are different, the XPath function is used differently to extract the HTTP or the HTTP With Entra Id actions:

• XPath(<flow definition actions object>,'//inputs[uri]') will return an array of all the “inputs” properties which contain a “uri” property from the actions object: what we want for the HTTP connector.
• XPath(<flow definition actions object>, '//parameters[request_x002F_method]') will return an array of all the “parameters” properties which contain a “request_x002F_method” property from the actions object: what we want for the HTTP With Entra Id connector.

We can then re-convert the results of these expressions into Json to iterate through each relevant action and process the needed information.

The Model Driven App: Endpoint Analyzer

The Model Driven App is a single-table App created to browse through the collected Endpoints. Ultimately, it is likely that organizations wanting to use this solution will include the table as part of their existing CoE Kit Admin App. Since it has a relationship with the Flow table of the CoE Kit, it is easy to navigate from an Endpoint to the related Flow and vice-versa.

The Power BI Template: HTTP Endpoints Reports

This is a simple single-page Power BI report template to show some basic reporting for the endpoints configured in the cloud flows from the tenant. As for the Model Driven App, it would make sense to include this report as part of the existing CoE Kit Dashboard rather than keeping it as a standalone one.

When opening the template, there is a parameter to define the Url of the CoE Kit environment, which will then set up the report and load the data.

Limitations

As stated at the beginning, this solution is not perfect to monitor HTTP Endpoints. The main limitations are:

• The logic is detect hard-coded passwords and secret is not perfect. If variables are used but the passwords are still hard-coded in the variables, the current solution will not flag it as such. Ideally it would.
• The flow is not currently able to re-compose the Uri that are dynamically defined, which result in the Host to not be defined in many situations neither. In some situation it should be technically feasible, for example:
  • When a local variable is used, the flow could check if it is set with a hard-coded value, in which case it would be able to replace the dynamic part by the actual value
  • When an environment variable is used, the flow could check its current value in Dataverse too,
  • When it is an output of a previous action it could attempt to look at the last flow run to see if it can be extracted from there.
• I am only covering the HTTP and HTTP With Entra Id connector, but the scope could be wider. For example it could include the “When an HTTP Request is Received” trigger and “HTTP Webhook”.

If you have any suggestion to improve above or any other aspects of the solution please let me know!