FIC credentials are broken when the app is deployed on K8

[bgavrilMS]

Microsoft.Identity.Web Library

Microsoft.Identity.Web

Microsoft.Identity.Web version

2.19.1

Web app

Sign-in users

Web API

Protected web APIs (validating tokens)

Token cache serialization

In-memory caches

Description

Id.Web fails to fetch a token when using FIC+MSI, if the app is deployed to Kubernetes

Reproduction steps

1. Configure a FIC + MSI like:

"ClientCredentials":[
   {
      "SourceType":"SignedAssertionFromManagedIdentity",
      "ManagedIdentityClientId":"GUID"
   }
]

2. Deploy app on Kubernetes, where kubelogin is configred
3. Use MISE CallApi or Id.Web DownstreamAPI etc.

Actual:

[MsIdWeb] Not using Managed identity for client credentials: ClientAssertionCredential authentication failed: AADSTS1002012: The provided value for scope api://AzureADTokenExchange is not valid. Client credential flows must have a scope value with /.default suffixed to the resource identifier (application ID URI). Trace ID: bb815fb3-3f99-4a0a-8767-e34147a08900 Correlation ID: e8e4bf4d-8461-42ca-bfeb-28224fbda7f6 Timestamp: 2024-06-12 02:51:00Z.

Notice the name of the credential that is failing - ClientAssertionCredential. This is not ManagedIdentityCredential as you'd expect. ClientAssertionCredential is part of WorkloadIdentityCredential

Root cause

This is due to the use of DefaultAzureCredential (DAC) here. DAC will first try WorkloadIdentity and then ManagedIdentity

So what happens is that WorkloadIdentity will kick in, because we're on Kubernetes and kubelogin is configured. WorkloadIdentityCredential read the assertion from a file and then Id.Web incorrectly asks for a token for api://azureAdTokenExchange (the assertion has that audience already, we don't need to ask for it!).

WorkloadIdentityCredential then fails with the above message.

Proposed solution

Workload Identity never worked with Id.Web, so it is safe to remove. We should add as an explicit SourceType. SignedAssertionFromManagedIdentity is not WorkloadIdentity and the TokenExchangeUrl config doesn't even make sense.

Error message

[MsIdWeb] Not using Managed identity for client credentials: ClientAssertionCredential authentication failed: AADSTS1002012: The provided value for scope api://AzureADTokenExchange is not valid. Client credential flows must have a scope value with /.default suffixed to the resource identifier (application ID URI). Trace ID: bb815fb3-3f99-4a0a-8767-e34147a08900 Correlation ID: e8e4bf4d-8461-42ca-bfeb-28224fbda7f6 Timestamp: 2024-06-12 02:51:00Z.

Id Web logs

No response

Relevant code snippets

So many mandatory boxes...

Regression

No response

Expected behavior

token

[bgavrilMS]

Possible P1 as it blocks a fairly big scenario on Kubernetes.

[jennyf19]

For AKS, partners need to use

"ClientCredentials":[
    {
    "SourceType": "SignedAssertionFilePath",
    "SignedAssertionFileDiskPath": "optional path to signed assertion"
   },
]

TokenExchangeUrl is needed in the sovereign cloud scenarios, is that correct @jmprieur ?

[jmprieur]

yes, this is right. for "SourceType":"SignedAssertionFromManagedIdentity", TokenExchangeUrl is needed in the sovereign cloud scenarios, @jennyf19

[bgavrilMS]

The problem is not TokenExchangeUrl, the problem is WorkloadIdentityCredential

Let me try to explain again.

Expected

1. (step 1 of FIC) Acquire a token for scope / audience api://azureADTokenExchange from some "assertion provider" like MSI or K8
2. (step2 of FIC) ID.Web then uses this token as a client assertion in MSAL to get a token for some resource, e.g. "KeyVault"

Actual

1. Id.Web tries to get a token for api://azureADTokenExchange using Azure.Identity's DefaultAzureCredential
2. Internally, this calls to WorkloadIdentityCredential first. And since the app is hosted on K8, this triggers. So what it internally does is:

• get a token from a file. this token corresponds to step1 of FIC. It has the correct audience api://azureADTokenExchange already
• tries to do step2. It will do a client_credentials call with this token. The scope it is going to use is api://azureADTokenExchange which is wrong! This is where the error occurs.

Today, you cannot use WorkloadIdentityCredential at all to provide the K8 FIC functionality in Id.Web. There is no SDK out there that exposes only step1 of WorkloadIdenitity + FIC.

[jmprieur]

@bgavrilMS : why do people try to use SignedAssertionFromManagedIdentity on AKS and not SignedAssertionFileDiskPath?
This sounds the problem?