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?

[richardcarrigan]

FWIW, here's the bash version that I went with:

# azure-pipelines.yml

trigger: none
pool:
  vmImage: windows-latest
stages:
  - stage: UAT_Deploy
    jobs:
      - deployment: DeployToUAT
        displayName: Deploy Power Platform solutions to UAT
        environment: 'uat' # creates an environment if it doesn't exist
        strategy:
          runOnce:
            deploy:
              steps:
                - checkout: self
                - task: NuGetAuthenticate@1
                  inputs:
                    forceReinstallCredentialProvider: false
                - task: CmdLine@2
                  displayName: Install Power Platform CLI
                  inputs:
                    script: |
                      dotnet tool install --global Microsoft.PowerApps.CLI.Tool
                - task: PowerPlatformToolInstaller@2
                  inputs:
                    DefaultVersion: true
                - task: PowerPlatformWhoAmi@2
                  inputs:
                    authenticationType: 'PowerPlatformSPN'
                    PowerPlatformSPN: 'uatserviceconnection'
                    Environment: '$(UAT_URL)'
                - task: Bash@3
                  displayName: Deploy solutions
                  inputs:
                    filePath: 'deploySolutions.sh'
                  env:
                    url: $(UAT_URL)
                    envName: $(UAT_ENV_NAME)
                    applicationId: $(UAT_CLIENT_ID)
                    tenant: $(TENANT)
                    PAC_ADO_ID_TOKEN_REQUEST_TOKEN: $(System.AccessToken)
                    PAC_ADO_ID_TOKEN_REQUEST_URL: '$(System.CollectionUri)$(System.TeamProjectId)/_apis/distributedtask/hubs/$(System.HostType)/plans/$(System.PlanId)/jobs/$(System.JobId)/oidctoken?serviceConnectionId=$(SERVICE_CONNECTION_ID)&api-version=7.2-preview.1'

# deploySolutions.sh

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

[tehcrashxor]

Looks like ADO had a recent release where they are now setting the System.OidcRequestUri. It still needs the api-version and serviceCeonnectionId parameters provided in the query string, but reduces the steps needed to construct the url.

[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.

[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.