[Feature Request] Is MSAL.Net compatible with workload identity federation credential?

[SCOMnewbie]

MSAL client type

Confidential

Problem Statement

Hi MSAL team,
After several hours in the docs, it seems MSAL.Net does not provide a way to interact with the workload identity federated credentials:

Is it me that missed the implementation? Or is it something you plan to provide later?

Cheers!

Proposed solution

No response

Alternatives

No response

[bgavrilMS]

What is the other federation provider that you intend to use there? Is it external (e.g. GitHub) or internal (i.e. AAD - for multi-tenantcy scenarios)?

I expect that can use WithClientAssertion instead of WithSecret or WithCertificate to pass in the token from the "other" identity provider.

I would think you'd want to do something like this:

public async Task<string> FetchGitHubTokenAsync() 
{
    // logic to get token from cache or from GitHub
     return token;
}

var cca = ConfidentialClientApplicationBuilder
                       .Create(client_id)
                       // easy token caching, 
                       // for high scale see 
                       // https://learn.microsoft.com/en-us/entra/msal/dotnet/how-to/token-cache-serialization?tabs=aspnet
                       .WithCacheOptions(CacheOptions.WithCacheOptions) 
                       .WithClientAssertion((options) => FetchGitHubTokenAsync() ) 
                       .Build();

var result = await cca.AcquireTokenForClient(new[] { "resource/.default "}).ExecuteAsync();

It's important to think about the lifetime of objects:

• the assertion from GitHub will expire, so we need to keep requesting a fresh one. Hence the user of WithClientAssertion(Func)
• avoid making too many calls to GitHub, i.e. ensure FetchGitHubTokenAsync gets cached tokens
• cache AAD tokens too, see https://learn.microsoft.com/en-us/entra/msal/dotnet/how-to/token-cache-serialization?tabs=aspnet

[bgavrilMS]

We should update the WithClientAssertion docs to ensure that we mention this scenario, so that Goog.. Bing indexes this.

We should also have a code snippet on https://learn.microsoft.com/en-us/azure/active-directory/workload-identities/workload-identity-federation that showcases this.

[jmprieur]

There is also a specialization for managed identity federation with MSI (private preview) and managed identity federation for AKS. See https://github.com/AzureAD/microsoft-identity-web/wiki/v2.0#credentials-are-generalizing-certificates

[SCOMnewbie]

Thank you for the quick answer. WithClientAssertion was my choice, but every time, I've received the error message like "your JWT is malformed", this is where I've started to think that it was not implemented. When you read https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/web-apps-apis/confidential-client-assertions, the only example Microsoft provides is when you forge your token yourself, sign it and use it with WithClientAssertion which is not the same scenario.

Here what I try to do: https://azure.github.io/azure-workload-identity/docs/installation.html

Long story short, workload identities on a K8s cluster. I look forward for the example you can provide. I will take a look at
Microsoft.Identity.Web but it feels like a another dependency I don't want to have in my scenario.

[bgavrilMS]

Hi @SCOMnewbie

Am I right in understanding that you are trying to setup a workload running on any Kubernetes cluster (Azure Kubernetes Service (AKS), Amazon Web Services EKS, Google Kubernetes Engine (GKE), or on-premises). Establish a trust relationship between your user-assigned managed identity or app in Microsoft Entra ID and a Kubernetes workload as per https://learn.microsoft.com/en-us/azure/active-directory/workload-identities/workload-identity-federation#supported-scenarios ?

From an SDK perspective, this should be possible with both MSAL and Azure Identity (they mostly use MSAL underneath and provide higher level APIs). As you can see in the examples, the code just uses MSAL via WithClientAssertion(jwtFromAKS) so I don't think there's anything wrong with your app code.

The docs do say the AKS cluster acts as token issuer, Azure Active Directory uses OpenID Connect to discover public signing keys and verify the authenticity of the service account token before exchanging it for an Azure AD token..

It is not clear from the docs, but you have to create an application in your AAD tenant and establish trust between it and your Kubernetes token issuer. Was this done?

then...

I think our friends from Azure SDK are in a better position to help, as they have documented this scenario end to end https://github.com/Azure/azure-workload-identity/tree/main

[SCOMnewbie]

Hi @bgavrilMS,
Thank you for the help, I've succeed to get my token. MSAL is definitely compatible with workload identity federated credentials!
Cheers

[pmaytak]

@bgavrilMS Can we reopen? I was thinking about adding a doc on MS Learn - this question have been asked a few times.

[bgavrilMS]

I also created a PR to update the Workload Identity sample docs:

Azure/azure-workload-identity#1146

[pmaytak]

The doc will be here once this PR is merged.