Login into a Managed Identity using federated credentials

[jkroepke]

Core Library

MSAL.js v2 (@azure/msal-browser)

Core Library Version

2.34.0

Wrapper Library

Not Applicable

Wrapper Library Version

None

Public or Confidential Client?

Public

Description

Hi,

I may ask is msal.js allows to initiate a login into a Managed Identity using Federated Credentials / Workload Identity

For compliance rules, I can't use Azure AD B2C. I have a company owned IDP that issue OIDC token. From technical point of view, I could use this token to login assume a Managed Identity used Workload Identity concept. Each single user would represent a Managed Identity on my subscription. In conclusion I can guarantee that only the OIDC user has access to the associated blob storage account and I could get rid of a central identity which has access to all blob storage account.

I'm not looking for a OIDC workflow here, I'm more interest into a token exchange.

Thats the process I'm looking for. In my case, the user is the workload here.

MSAL Configuration

No response

Relevant Code Snippets

No response

Identity Provider

Other

Source

External (Customer)

[sameerag]

@jkroepke MSAL has plans to support managed identity but we are yet to close on the design and timelines for the same. Let me reach out when we have more information.

cc @EmLauber

[EmLauber]

@jkroepke Managed Identity support is only planned for confidential clients, not a public client application using MSAL.browser. I recommend looking at Managed Identity support in MSAL.net or one of our other MSAL confidential client libraries that are looking to add support.

[jkroepke]

@EmLauber Is there a reason why MSAL Browser will not support the confidential client type? Please remember, for Workload Identity, a pre existing OIDC token from the user has to be used as secret instead server sided secret.

[EmLauber]

@jkroepke MSAL.node, which is under the larger MSAL.js umbrella, can be used with confidential clients. Your issue though had MSAL.browser which is meant for single-page applications that are run entirely in the browser. It sounds like what you are looking for is a frontend application using MSAL.browser that calls to a midtier that can do the OIDC token exchange against Azure AD to get the Workload Identity token. You can provision that midtier using one of the MSAL libraries that support confidential client flows, not MSAL.browser.

To Sameera's comment on timelines for Managed Identity support, as of right now, MSAL.net has support for Managed Identities. Other confidential client MSALs like MSAL.java and MSAL.node have support for Managed Identities on the horizon but I don't have a timeline to share.

[jkroepke]

Hi @EmLauber

there is no need for a midtier. the clients browser should to the token exchange with AzureAD by using the users OIDC token from a 3rd party identity.

For example, there is a Azure Storage Account and a MI which has access to the storage account.

The SPA will initiate a login with a OIDC complaint identity provider which is not Azure AD. Then the SPA can re-use the OIDC token todo a token exchange with Azure AD. With that token, the SPA can directly communicate with the storage account without any mid tier application in between.

In that case, each user as a own/dedicated managed identity.

Storage Account is only an example service here.

[iambmelt]

@jkroepke The flow you are referring to is a client credentials flow which is only available to confidential client applications. To establish the federation, you need to use the 'Certificates & secrets' pane which will require you to configure a secret or choose from a selection of preconfigured connections in order to create the federation. MSAL.js (as a public client) cannot keep or provide a secret securely, therefore the use of a mid-tier is required

[jkroepke]

@iambmelt did you configure a federated credential there? I wont get a credential back to keep secure.

[jkroepke]

I this case, first I would recommend to go away from the pattern, that a confidential client is requirement and using a confidential client cant be keep secured in that browser.

In this specific case, federated credentials requires a OIDC Token to log into it. In this case, the OIDC Token is short-term and issued an client level.

In this case, the mid-tier application would use the token from a user passed from the request and initiate the token exchange.

Whats the reason, why the browser of the user can't initiate the token exchange directly? In that scenario, each user had a own, dedicated managed identity. There are no additional mid tier application credentials required.

User generated credentials are used here to log into it.

[iambmelt]

A confidential client flow is needed to ensure that a malicious app doesn't supply your applications client id as part of the request. Without a client secret, there is no way to assert the identity of the calling application is genuine and prevent impersonation.

[jkroepke]

Hi @iambmelt

Thats the goal is that the users do a direct impersonation of the managed identity, since 1:1 relationship between the user and the managed identity

In this use case

• A confidential client will be used
• A static client secret will be not used, instead
• A federated credential configuration will be configured on the managed identity. Each user of my applications gets a own managed identity.

A confidential client without a static secret is the use case for Azure Workload Identity.

Then

• A personalized federated credential issued by an 3rd party OIDC issuer on users login.
• The users browser will do a token exchange with Azure AD without any mid-tier application and impersonate the managed identity directly. The issued token from the 3rd party OIDC is signed and Azure AD will trust the signature.
• The users browser directly call the AzureAD without any mid-tier application.

In this scenario, the client secret that is used for the token exchange is already known by the user, since its the own token of the users.

[jkroepke]

Hi @iambmelt , @EmLauber

how to move forward here? I explain a technical valid reason for allowing such kind of Confidential Clients on the browser level. To summarize it, the client credential used to authenticate against a Managed Identity is a JWKS token signed by 3rd party authority. The 3rd party authority is configured as part of the Federated Credentials. The token gets returned to the SPA and is already know by the user before assume the managed identity.

This eliminate the wording Confidential Clients can not work on browser level. The client secret is already known by user and uniques to that user session. (token by 3rd party authority have a expire date).

A 3rd party authority can be any OpenID Connect-compatible identity provider such as Google or Keycloak.

AWS supports this use case and there is a more technical description on that concept:

https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-sts/classes/assumerolewithwebidentitycommand.html

Translation table:

Azure	AWS
Workload Identity	AssumeRoleWithWebIdentity
Managed Identity	IAM Role
Azure AD	AWS STS

[EmLauber]

I appreciate your explanation of this use cause. After reviewing, MSAL.browser does not have plans to support this scenario. I recommend one of the MSAL libraries that support confidential client flows already. I have taken down your feedback though and will consider it in future planning.