Workload Identity Federation Preview

[tehcrashxor]

With the release of Power Platform Build Tools v2.0.69 and its underlying PAC v1.32.6, Service Principals can now authenticate with OpenID Connect (OIDC), federated with Azure DevOps . This enables the removal of Service Connections with Client Secrets.

To use this new option:

1. Create a new Power Platform Service Connection, select "Workload Identity federation (preview)", and supply your Dataverse Organization URL, Service Principal ID (App ID), and Tenant ID
2. Configure the App Registration in the Azure Portal with federated credentials to your Azure DevOps org

Add Federated Credentials to the App Registration

1. Go to App registrations in the Azure Portal and open the app associated with your Service Principal
2. Select Certificates and Secrets in the Manage panel
   
3. In the Federated credentials tab, select Add credential
   
4. Select the credential scenario Other issuer, and set the Issuer and Subject identifier fields for your Azure DevOps Service Connection
   

• The Issuer field must be https://vstoken.dev.azure.com/[AzureDevOpsOrganizationID]
• The Subject identifier field must be in the format sc://[AzureDevOpsOrganizationName]/[AzureDevOpsProjectName]/[AzureDevOpsServiceConnectionName]
• If these values are missing or misconfigured, running any of the Power Platform Build Tools tasks with a misconfigured Workload identity will output the expected values to the Pipeline logs.

[richardcarrigan]

This is HUGE and works perfectly for tasks which invoke the service connection directly.

For one of my use cases, however, I'm running pac auth create --url $url --name $envName --applicationId $applicationId --tenant $tenant --azureDevOpsFederated inside of a Bash script file executed by the ADO pipeline, but I'm getting the error Error: Execution environment is either not an Azure DevOps Pipeline or is not configued correctly. Required PAC_ADO_ID_TOKEN_REQUEST_TOKEN or PAC_ADO_ID_TOKEN_REQUEST_URL environment variables are missing. When I try to inject these into the Bash execution environment using the env param for the Bash@3 task, I then get the error Error: Request to Azure DevOps Token Federation endpoint failed.

# azure-pipelines.yml

- task: Bash@3
  displayName: Deploy solutions
  inputs:
    filePath: 'deploySolutions.sh'
  env:
    url: $(PP_ENV_URL)
    envName: $(PP_ENV_NAME)
    applicationId: $(CLIENT_ID)
    tenant: $(TENANT)
    PAC_ADO_ID_TOKEN_REQUEST_TOKEN: $(PAC_ADO_ID_TOKEN_REQUEST_TOKEN)
    PAC_ADO_ID_TOKEN_REQUEST_URL: $(PAC_ADO_ID_TOKEN_REQUEST_URL)

# deploySolutions.sh

pac auth create --url $url --name $envName --applicationId $applicationId --tenant $tenant --azureDevOpsFederated

What am I missing?

[TalviArt]

Is there a limitation which Power Platform CLI Commands/Command Groups can be used in pipeline task after authenticating with temporary auth profile? I'm able to run for example "pac env who" and "pac solution list", but when trying to run "pac application list" I get an error:

"Error: Execution environment is either not an Azure DevOps Pipeline or is not configued correctly. Required PAC_ADO_ID_TOKEN_REQUEST_TOKEN or PAC_ADO_ID_TOKEN_REQUEST_URL environment variables are missing"

I wonder why the other pac commands works but "pac application list" throws an error.

[petrochuk]

Each command/command group might call different APIs which might need separate permissions. For example env list calls Global Discovery Service, in your case pac application list calls Power Platform API Applications - Get Environment Application Package

[TalviArt]

Thanks for the reply.

The issue seemed to be pac application list not able to find PAC env variables when executed in separate PowerShell@2 tasks after the authentication profile was created. Running the pac application list in the same PowerShell@2 task with pac auth create worked.

[mathiasbl]

Thanks @richardcarrigan! Here is a working example for others to follow / adapt.

trigger: none
pool:
  vmImage: ubuntu-latest
variables:
  BuildTools.EnvironmentUrl: "YOUR-URL"
steps:
- task: PowerPlatformToolInstaller@2
  inputs:
    DefaultVersion: true
    AddToolsToPath: true
- task: PowerPlatformWhoAmi@2
  inputs:
    authenticationType: 'PowerPlatformSPN'
    PowerPlatformSPN: 'YOU-SVC-CONN-NAME'
- task: PowerShell@2
  env:
    PAC_ADO_ID_TOKEN_REQUEST_TOKEN: $(System.AccessToken)
  inputs:
    targetType: 'inline'
    script: |
      $uri = "$(System.CollectionUri)"
      $projectId = "$(System.TeamProjectId)"
      $hub = "$(System.HostType)"
      $planId = "$(System.PlanId)"
      $jobId = "$(System.JobId)"
      $serviceConnectionId = "YOUR-SVC-CONN-ID"
      $oidcApiVersion = "7.2-preview.1"
      $env:PAC_ADO_ID_TOKEN_REQUEST_URL = "$uri$projectId/_apis/distributedtask/hubs/$hub/plans/$planId/jobs/$jobId/oidctoken?serviceConnectionId=$serviceConnectionId&api-version=$oidcApiVersion"
      $environment = "$(BuildTools.EnvironmentUrl)"

      pac auth create --name devops-temp --environment $environment --azureDevOpsFederated --tenant YOUR-TENANT-ID --applicationId YOUR-APP-ID
    pwsh: true
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      pac env who
    pwsh: true
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      pac solution list
    pwsh: true

@devkeydet
This example stops working as soon as you remove the Who Am I action.
The first powershell actually does nothing because the whoami action already authenticated so it just reuses that connection.

I cannot get it to work using the oidcRequestUri even with a plain example like mentioned here: https://learn.microsoft.com/en-us/azure/devops/release-notes/2024/sprint-240-update#azure-cli

[geekzter]

You will not be able to get an OIDC token for a service connection that is not used in a task in the pipeline job you're requesting a token for.

[Dohsan]

We have started to move over to using the Workload Identity federation.

Noticed an issue using the PowerPlatformSetConnectionVariables@2 task

# yaml
            - task: PowerPlatformSetConnectionVariables@2
              displayName: 'Get Service Principal Credentials'
              name: SP_credentials
              inputs:
                authenticationType: 'PowerPlatformSPN'
                PowerPlatformSPN: ${{ parameters.SPN }}             

##[warning]LIB_ResourceFile does not exist
##[warning]Resource file haven't been set, can't find loc string for key: LIB_EndpointAuthNotExist
##[error]Error: LIB_EndpointAuthNotExist

Not something we've seen before and replicated it on both pipelines where we'd updated the Service Connection to use WIF

Other tasks using the SPN worked with no issue.

[tehcrashxor]

Hmm.
Looks like that code path only expects SPNs to be using Client Secrets, and would break in the same way for Managed Identities.

@devkeydet , there isn't a Dataverse Connection String that works for Managed Identities or Federated flows, but we could still set the other values. Thoughts? Might tie into discussion #906

[devkeydet]

I wouldn't expect to be able to use PowerPlatformSetConnectionVariables with workload identify federation. The variables set when using SPN or Username/Password are not there in the service connection. I do not think there is a connection string format to use workload federated identity. @MattB-msft might have some thoughts on what it would take to get clients that use the connection string format to use the token created via workload identity federation.

[seanmcne]

Dropping this here, for anyone else looking for how to find the "AzureDevOpsOrganizationID" value (courtesy of @tehcrashxor) #916 (comment)

With the release of Power Platform Build Tools v2.0.69 and its underlying PAC v1.32.6, Service Principals can now authenticate with OpenID Connect (OIDC), federated with Azure DevOps . This enables the removal of Service Connections with Client Secrets.

To use this new option:

1. Create a new Power Platform Service Connection, select "Workload Identity federation (preview)", and supply your Dataverse Organization URL, Service Principal ID (App ID), and Tenant ID
2. Configure the App Registration in the Azure Portal with federated credentials to your Azure DevOps org

Add Federated Credentials to the App Registration

1. Go to App registrations in the Azure Portal and open the app associated with your Service Principal

2. Select Certificates and Secrets in the Manage panel

3. In the Federated credentials tab, select Add credential

4. Select the credential scenario Other issuer, and set the Issuer and Subject identifier fields for your Azure DevOps Service Connection

• The Issuer field must be https://vstoken.dev.azure.com/[AzureDevOpsOrganizationID]
• The Subject identifier field must be in the format sc://[AzureDevOpsOrganizationName]/[AzureDevOpsProjectName]/[AzureDevOpsServiceConnectionName]
• If these values are missing or misconfigured, running any of the Power Platform Build Tools tasks with a misconfigured Workload identity will output the expected values to the Pipeline logs.

[h-karthik12]

$(System.CollectionId) variable also fetches the OrganizatonID

[Hjaf]

How federated credentials can be utilized with GitHub Actions was not very clear from the documentation, but it seems to be pretty straight forward with the right setup. I'm just putting this here in case someone else struggle to understand the documentation for this like I did; eventually finding themselves at this discussion.
I'm assuming the credentials in the app registration (GitHub) is set up correctly for the repository where the action is triggered.

The permissions section of the GH-action needs to be set for the id-token to be updated:

permissions:
  id-token: write

See GitHub docs for more info

Omitting the client-secret from the steps, is all that is needed for federated authentication to be used:

This is detected automatically from what i understand of this PR

    - name: Install PAC
      uses: microsoft/powerplatform-actions/actions-install@v1
      with:
        add-tools-to-path: true
        
    - name: who-am-i action
      uses: microsoft/powerplatform-actions/who-am-i@v1
      with:
        environment-url: ${{ env.DATAVERSE_ENVIRONMENT_URL }}
        app-id: ${{ env.CLIENT_ID }}
        tenant-id: ${{ env.TENANT_ID }}
        # client-secret: ${{ secrets.CLIENT_SECRET }} # <-- Removing this seems to be sufficient. 

[filcole]

Workload Identity Federation is not working, have logged #1212.

[pierozek89]

I tried every possible combination and manual I found. Still I got error with action "PowerPlatformWhoAmi@2"

##[error]failed: The Service Principal's Federated Credentials may be misconfigured in the Azure Portal. The Issuer field should be set to [], and Subject Identifier field should be set to []. w`

[bguidinger]

The documentation above is outdated/incorrect. For the Federated Credentials on the App Registration, you need to use the Issuer and Subject Identifier that Azure DevOps shows on the Service Connection after you create it.

[CalebBartleMAA]

This is the CORRECT answer and how it should be done. Thank you.