Set up Workload Identity federation for ADO Connection

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.

Background

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.

Workload Identity Federation vs. Managed Identity

Another question I asked myself and I get from others is what the difference is between Workload Identity Federation and Managed Identity.

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

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.

Setup

This chapter will show you how to set this up.

Create App Registration

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

• log in to the Azure portal – in the Tenant where the target Dataverse is located
• open Microsoft Entra ID
• navigate to App Registrations
• click on “New registration”

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.

Configure Dataverse

Next, we have to add the App Registration to Dataverse and give it a security role.

To do that we:

• Open the Power Platform Admin Center
• Navigate to the Environments list
• Select the Environment we need in our pipeline

• On the overview page, we open Settings

• Here we select “Application users” under the “User + permissions” group

• On the following screen, we select “+ New app user”, which opens a fly-out
• Select “+ Add an app”
• Search for either the name or App Id
• Select the correct App Registration
• Select a Business unit
• Assign a Security role by selecting the little pen icon on the right side
• Click Create to create the user

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.

Create Service Connection

Now we will create the service connection in Azure DevOps.

• Navigate to the project settings and the service connections
• Press “New service connection” – this will open a fly-out from the right side

• In the fly-out we select Power Platform as the connection type
• Press Next

• On the next screen, we have to present/select
  • Workload Identity federation
  • Server ULR- Which is the URL to our Dataverse environment
  • Service Principal ID – This is the Application (client) ID from the App Registration overview
  • Tenant ID – This is the Directory (tenant) ID from the App Registration overview
  • Service connection name – We need this for one of the next steps
  • Check “Grant access permission to all pipelines”
• Press Save

This Service connection can now be used in steps from the Power Platform Build Tools for Azure DevOps.

Set up Workload Identity Federation

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 App Registration go to “Certificates & secrets”
• Open the “Federated credentials” tab
• Select “+ Add credential”

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.

Get the ADO Organization ID

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.

Conclusion

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.