Application ID and client secret were the preferred way of authenticating Azure DevOps (ADO) to a Dataverse instance. For a few months, there has been a new way of doing this part, workload identity federation. This blog post will show you how to set up Workload Identity federation for ADO connection.
The service connection we will set up can be used in any step of the Power Platform Build Tools for Azure DevOps (docs & Marketplace).
Be aware that this setup is only possible if your ADO Organization is connected to an Entra Tenant. This means if you are using an onPrem AD this won’t work.
Let’s discuss the background a bit. With Application ID and client secret authentication, the problem is that the secret usually has a certain lifetime. This means that when the expiration date is passed, our pipeline will stop working.
One common request I get from colleagues and customers is: “Our pipelines do get an error. Can you look at it?”. Often it is because the secret has expired.
In one of my earlier blog posts, App Secret valid longer than 24 months, I explained how we can create a secret that does not have an expiration date. But this approach isn’t intended by Microsoft.
This new approach, Workload Identity Federation aka federated identity, makes the secret obsolete. The idea is that we configure both ends (ADO and App Registration) in a way that they allow ADO to use the App Registration without the need of a secret.
With that, our pipelines will be authenticated without the need to create and configure new secrets.
Another question I asked myself and I get from others is what the difference is between Workload Identity Federation and Managed Identity.
Managed Identity is implementing a secretless way of authentication. The scope is one Tenant and only Azure.
This means a managed identity can only be used in Azure and only to authenticate between resources within the same tenant.
Since both Dataverse and Azure DevOps not directly are in your Azure Tenant you can’t use them in either of those two.
This is also the reason why I find the naming of the new feature, Use managed identities for Dataverse plug-ins, very confusing and misleading. What is implemented here is a workload identity federation intended for ISVs to communicate from a customer tenant to their own.
Workload Identity Federation on the other hand implements a secretless way of authentication to resources outside of your Azure tenant. This means for example hybrid or multi-cloud setups.
This also allows you as a consultant to execute cross-tenant deployments without secrets. For example to deploy your products to the customer’s environments.
Here you can read more about Workload Identity Federation.
This chapter will show you how to set this up.
First of all, we would need to create a new App Registration.
To be able to do the following steps you need certain permissions within the desired Azure subscription. Those are documented on Microsoft Docs. In general, the owner of a subscription is allowed to create App Registrations within the given subscription.
To do so we
In the next screen, you can give your App Registration a good name. I took “WFI Demo”. All the other parts can be left as the default is.
If you try to set up a cross-tenant deployment you would have to choose “Accounts in any organizational directory”
Click on “Register” to create the App Registration.
After you have created the App Registration you will come to the overview. Here you can copy parts of the information you will need later.
For now, that is all we need here. We will come back to this App Registration later.
Next, we have to add the App Registration to Dataverse and give it a security role.
To do that we:
For Application Users used for deployments in a pipeline, I tend to assign the System Administrator role. This is the only exception where I find that is okay since a deployment needs access to basically everything in the environment.
Now we will create the service connection in Azure DevOps.
This Service connection can now be used in steps from the Power Platform Build Tools for Azure DevOps.
To make the whole set up workload identity federation for ADO connection work we have to add another configuration to the App Registration.
On the next screen, we select “Other issuer” as the “Federated credential scenario”.
The Issuer needs to be “https://vstoken.dev.azure.com/” followed by your ADO Organization ID. In the next section, we will learn how to retrieve this ID.
Subject Identifier should be “sc://<ADO Organization name>/<Project Name>/<Service Connection name>”. In my case for example: sc://b*****p/Demo/DEV WFI.
In case either your Project name or service connection name contains spaces they should be left as spaces and not URL encoded.
Lastly, we have to give it a good name. After that, we can save it
This step has to be done for every service connection which should use this app Registration. This means usually we do it three times (DEV, Test and Prod)
With that our setup is complete and we can connect from Azure DevOps to our Dataverse Environment without a secret that expires.
Getting the ID of your Azure DevOps Organization isn’t something that is straightforward and slightly confusing. To get it we navigate to the Organization Settings of your ADO.
On the next page navigate to “Microsoft Entra”. Here you can find to which Microsoft Entra your ADO is connected. By pressing “Download” we can download a CSV file with all the Azure DevOps organizations connected to your Microsoft Entra directory/tenant.
In that CSV file you have to find the correct entry for your ADO Organization in question. The first column is the Organization ID which you need to paste into the end of the URL in the issuer.
There are quite a few steps to set up workload identity federation for ADO connection. If you know which steps and how to find stuff (aka the ADO Org ID) it isn’t too hard and saves work and time in the long run.
I hope this blog post helped. Feel free to contact me with any questions or feedback you might have.
The post Set up Workload Identity federation for ADO Connection appeared first on Benedikt's Power Platform Blog.
Original Post https://benediktbergmann.eu/2024/11/28/set-up-workload-identity-federation-for-ado-connection/