Aside from Azure Traffic Manager, Azure Functions, and Azure Service Bus, Azure API Management (APIM) is one of my favourite services to use in just about any solution.
A useful little nugget for APIM is it’s able to have its own Managed Identity. You can choose to use a System Managed Identity or a User Managed Identity. Both options have pros and cons.
When you have configured APIM with a managed identity, this identity can be used to authenticate with the backend services.
This can be useful in a wide variety of scenarios, but do be careful configuring this. By using this feature, every request to the backend will use the token of the Managed Identity and not of your users or services making authenticated requests to APIM.
As mentioned in the docs, to set this up, you can use the authentication-managed-identity policy for inbound requests.
When doing so, you need to specify which backend resource to use (App URI ID of an App Registration), and the name of the variable to put the token into.
<policies>
<inbound>
<base />
<authentication-managed-identity resource="api://07601ff2-0b86-40f2-b5d9-7f8db33c9fb7/" output-token-variable-name="msi-access-token" ignore-error="false" />
<set-header name="Authorization" exists-action="override">
<value>@("Bearer " + (string)context.Variables["msi-access-token"])</value>
</set-header>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
Very useful in many scenarios, but do be careful of the downsides of using the APIM managed identity to be the authenticated party for backend services.
Read more →If you’ve read my previous post on how to create a Power Query custom connector with authentication, you might be wondering if the same can be achieved by using your own identity instead of a service principal being used.
The answer is: YES!
There are a couple of resources that I found helpful, but didn’t provide me with a complete answer, but did help me get to a solution. These are the ones I used as a reference:
Set up the authentication
In the previous post, the Anonymous authentication was used.
If you want to use your own account, and use Microsoft Entra ID, this should be changed to OAuth making the block look like this.
MyConnector = [
TestConnection = (dataSourcePath) => {"MyConnector.Contents"},
Authentication = [
// Anonymous = [], // Can be used when a Service Principal is used to authorize against the API
OAuth = [
StartLogin = StartLogin,
FinishLogin = FinishLogin,
Refresh = Refresh
]
]
];
The StartLogin, FinishLogin and Refresh are being invoked by the runtime and you need to define your own implementation on what needs to happen over there.
Read more →For a while we have been creating Power BI reports retrieving data from our API. This works quite nice, but our API has OAuth2 authentication & authorization in place. So far, we added a manually created access token to the data source and updated it on a regular basis. While this works, it’s not a very solid approach.
I figured we can (and should) do better so decided to investigate a bit on the topic. I quickly stumbled on creating your very own Power Query custom connectors that support having authentication on the connector, or use the OAuth2 endpoints by invoking the Web.Contents method.
Get started
To get started, there is an article on MS Learn called Using the Power Query SDK and Create your first connector: Hello World. These are great starting points in my opinion. Just to see how stuff works and create an initial project.
The major takeaways from this article are:
- Use VS Code
- Use the Power Query SDK
- Create a new project by using the Power Query SDK
There is another thing you need to know, which I learned the hard way.
You are required to use the Set credentials option for a connector. Even if you set Authentication to Anonymous, credentials are required.
Read more →